XARE: Marco de desarrollo para sistemas colaborativos conscientes

Transcripción

CENTRO DE INVESTIGACIÓN Y DE ESTUDIOS
AVANZADOS DEL INSTITUTO POLITÉCNICO
NACIONAL
UNIDAD ZACATENCO
DEPARTAMENTO DE COMPUTACIÓN
XARE: Marco de desarrollo para sistemas colaborativos conscientes
de contexto
Tesis que presenta
Gabriela Sánchez Morales
para obtener el Grado de
Doctora en Ciencias
en Computación
Codirectores de la Tesis
Dra. Sonia Guadalupe Mendoza Chapa
Dr. Dominique Decouchant
México, D.F.
Diciembre 2013
ii
iii
Resumen
Actualmente, la mayorı́a de las aplicaciones suponen que la interacción hombre-máquina está
confinada en un solo dispositivo de cómputo (e.g., una PC) donde el usuario emplea dispositivos de entrada/salida tradicionales (e.g., monitor, teclado y ratón). Sin embargo, la creciente
proliferación de dispositivos de cómputo y el progreso de las redes de comunicación potencialmente transforman al usuario en un ente que se desenvuelve en un ambiente variable y que
utiliza dispositivos de cómputo diversos, con el fin de satisfacer sus necesidades. Esta variedad
de dispositivos fijos y móviles (e.g., pizarrones electrónicos, tabletas digitales, PDAs y smartphones) impone nuevos requerimientos a las aplicaciones, como la capacidad de adaptarse a
cambios en el contexto de uso, definido en términos del usuario, de la plataforma y del entorno. Sin embargo, el desarrollo por separado de diferentes versiones de una misma aplicación
no sólo es extremadamente costoso en términos de desarrollo y mantenimiento, sino también
puede dar lugar a comportamientos ergonómicos inconsistentes. La plasticidad de sistemas
interactivos es una lı́nea de investigación que pretende ofrecer soluciones a estos problemas.
Esta lı́nea de investigación está inspirada en la propiedad de los materiales que les permite
expandirse y contraerse bajo restricciones naturales, sin romperse. Aplicada a sistemas interactivos, la plasticidad se refiere a la capacidad de adaptarse a cambios en el contexto de uso,
preservando un conjunto de criterios (e.g., usabilidad y continuidad). En el dominio de los
sistemas mono-usuario, la plasticidad ha sido estudiada principalmente mediante la definición
de algunos conceptos y el desarrollo de algunos prototipos de laboratorio. Por el contrario,
en el dominio de los sistemas colaborativos el estudio de interfaces plásticas prácticamente no
ha sido explorado a pesar de la necesidad inminente de dotar a las interfaces multi-usuario
de la propiedad de adaptación a cambios contextuales. En los sistemas colaborativos, la administración del espacio de despliegue es una actividad particularmente crı́tica, debido a que
una interfaz multi-usuario provee componentes gráficos para hacer uso de las funciones de la
aplicación, sino también ofrece componentes gráficos adicionales para remplazar la información
(coordinación y comunicación) que se pierde cuando los colaboradores no interactúan cara a
cara. Este proyecto de investigación pretende ofrecer soluciones tanto teóricas como prácticas
que faciliten el desarrollo de sistemas cooperativos plásticos.
iv
Índice general
Índice de figuras
ix
Índice de tablas
xiii
1 Introducción
1
1.1 Trabajo Cooperativo Asistido por Computadora . . . . . . . . . . . . . . . . . .
1
1.2 Interacción Humano-Computadora . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.3 Contexto de investigación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
1.4 Planteamiento del problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
1.5 Objetivos del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.6 Organización del documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2 Interfaces de usuario plásticas en sistemas interactivos
13
2.1 Problemas encontrados en las interfaces de usuario plásticas multi-modales . . . 13
2.2 Percutores de plasticidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2.1
Remodelación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2.2
Redistribución . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2.3
Migración . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.3 Granularidad de adaptación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.4 Granularidad de recuperación del estado . . . . . . . . . . . . . . . . . . . . . . 29
2.5 Despliegue de la interfaz de usuario . . . . . . . . . . . . . . . . . . . . . . . . . 30
v
vi
ÍNDICE GENERAL
2.6 Cobertura del contexto de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.7 Cobertura de espacio tecnológico . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.8 Meta-interfaz de usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.9 Otras dimensiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.9.1
Tipo de adaptación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.9.2
Sistemas mono-entidad o multi-entidad . . . . . . . . . . . . . . . . . . . 39
2.9.3
Variables contextuales . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.10 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3 Marcos de desarrollo de sistemas plásticos
43
3.1 Marco de Referencia Unificado para Interfaces de Usuario Multi-Objetivo . . . . 44
3.1.1
Modelos ontológicos, arquetı́picos y observadores . . . . . . . . . . . . . . 44
3.1.2
Implementación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.2 CAMELEON-RT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.2.1
Capas de sistemas interactivos, DMP y plataforma . . . . . . . . . . . . 49
3.2.2
Implementación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.3 Marco de Plasticidad Implı́cita . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.4 Marco de Plasticidad Explicita Colaborativa . . . . . . . . . . . . . . . . . . . . 53
3.4.1
Fases ARP, CRP, IMP y PIM . . . . . . . . . . . . . . . . . . . . . . . . 54
3.4.2
Implementación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.5 Marco para la Adaptación de la Conciencia de Contexto en Despliegues Públicos 56
3.6 Marco y Arquitectura para Recomendaciones de Conciencia de Contexto Grupal
59
3.7 Marco Genérico de Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.7.1
Capas de conocimiento, estado, contextualización y adaptación . . . . . . 61
3.7.2
Implementación
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.8 Análisis comparativo de los marcos analizados . . . . . . . . . . . . . . . . . . . 65
3.9 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
ÍNDICE GENERAL
vii
4 Análisis de requerimientos del marco XARE
73
4.1 Contexto de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.1.1
Recapitulación del contexto de uso de los sistemas mono-usuario . . . . . 74
4.1.2
Contexto de uso de los sistemas cooperativos . . . . . . . . . . . . . . . . 75
4.2 Relación entre escenarios y aplicaciones . . . . . . . . . . . . . . . . . . . . . . . 76
4.3 Escenario 1: Mejoramiento del trabajo colaborativo . . . . . . . . . . . . . . . . 79
4.3.1
Preámbulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
4.3.2
Descripción del escenario . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
4.3.3
Desktop enriquecido . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
4.4 Escenario 2: Remodelación de componentes de la interfaz de usuario . . . . . . . 89
4.4.1
Preámbulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
4.4.2
Descripción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
4.4.3
Editor de mapas mentales . . . . . . . . . . . . . . . . . . . . . . . . . . 92
4.5 Escenario 3: Redistribución del sistema colaborativo en función de la configuración del grupo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
4.5.1
Preámbulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
4.5.2
Planteamiento del escenario 3 . . . . . . . . . . . . . . . . . . . . . . . . 99
4.6 Escenario 4: Adaptar los medios de contacto y de disponibilidad . . . . . . . . . 101
4.6.1
Preámbulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
4.6.2
Planteamiento del escenario . . . . . . . . . . . . . . . . . . . . . . . . . 101
4.6.3
Herramienta disponibilidad y medios de contacto . . . . . . . . . . . . . 105
4.7 Escenario 5: Ocultar información . . . . . . . . . . . . . . . . . . . . . . . . . . 108
4.7.1
Preámbulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
4.7.2
4.8 Escenario 6: Adaptar la información . . . . . . . . . . . . . . . . . . . . . . . . 110
4.8.1
Preámbulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
4.8.2
4.8.3
Herramienta administrador de contenidos vı́a NFC . . . . . . . . . . . . 114
viii
ÍNDICE GENERAL
4.9 Escenario 7: Uso de diferentes modalidades en la notificación . . . . . . . . . . . 118
4.9.1
Preámbulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
4.9.2
4.10 Aplicaciones de prueba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
4.10.1 Herramienta de votación . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
4.11 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
5 Diseño del marco XARE
129
5.1 Diagramas de clases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
5.1.1
Diagrama de clase del contexto de uso de los sistemas cooperativos . . . 130
5.1.2
Diagrama de clases del vigilante . . . . . . . . . . . . . . . . . . . . . . . 134
5.2 Mecanismos del marco XARE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
5.2.1
Mecanismo de similaridad de actividades . . . . . . . . . . . . . . . . . . 137
5.2.2
Mecanismo de disponibilidad de un colaborador . . . . . . . . . . . . . . 139
5.2.3
Mecanismo de medios de contacto . . . . . . . . . . . . . . . . . . . . . . 142
5.2.4
Mecanismo de ocultar, sustituir y mostrar componentes . . . . . . . . . . 143
5.2.5
Mecanismo de creación de hiperligas entre los objetos compartidos . . . . 144
5.2.6
Mecanismo de proximidad lógica . . . . . . . . . . . . . . . . . . . . . . 146
5.2.7
Mecanismo tipo de trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . 148
5.3 Marco XARE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
5.3.1
Capas del marco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
5.4 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
6 Validación del marco Xare
6.1 API del marco Xare
157
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
6.2 Medio de contacto y disponibilidad”
. . . . . . . . . . . . . . . . . . . . . . . . 158
6.2.1
Dimensiones abordadas en esta propuesta
. . . . . . . . . . . . . . . . . 158
6.2.2
Relación entre la propuesta y el marco de adaptabilidad plástica . . . . . 161
ÍNDICE GENERAL
ix
6.3 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
7 Conclusiones y trabajo a futuro
167
7.1 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
7.2 Trabajo a futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
A Publicaciones
171
Referencias
173
x
ÍNDICE GENERAL
Índice de figuras
1.1 Visión general de la interacción multimodal mediante un enfoque centrado en el
usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
1.2 Contexto de investigación de este proyecto doctoral . . . . . . . . . . . . . . . .
7
1.3 Organización del documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1 Espacio del problema de las interfaces de usuario plásticas multimodales . . . . 15
2.2 Remodelación en el sistema de control de calefacción . . . . . . . . . . . . . . . 18
2.3 Todos los niveles de redistribución en el sitio Web de Sedan-Bouillon
. . . . . . 20
2.4 Niveles de redistribución de Roomware: de centralizada a centralizada (desde “c”
hacia “a”), de centralizada a distribuida (desde “a” hacia “b”) y de distribuida
a centralizada (desde “b” hacia “c”) . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.5 Niveles de redistribución de CamNote: de centralizada (en una PC) a distribuida
(entre una PC y una pocket PC) y viceversa . . . . . . . . . . . . . . . . . . . . 22
2.6 Niveles de redistribución de ConnecTables: de centralizada a distribuida y viceversa 22
2.7 Niveles de redistribución de MindMap: de centralizada a distribuida y viceversa
23
2.8 Grano de adaptación en otros sistemas interactivos . . . . . . . . . . . . . . . . 24
2.9 Grano de adaptación a nivel de tarea en FlexClock . . . . . . . . . . . . . . . . 25
2.10 Granos de adaptación a nivel total y de interactor en el sistema de control de
calefacción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.11 Grano de adaptación a nivel de espacio de trabajo en el sitio Web de Sedan-Bouillon 27
2.12 Grano de adaptación a nivel de espacio de trabajo en el sistema Ubidraw . . . . 27
2.13 Grano de adaptación a nivel de espacio de trabajo en el sistema CamNote
. . . 28
2.14 Grano de adaptación a nivel de pı́xel en el sistema Roomware . . . . . . . . . . 28
xi
xii
ÍNDICE DE FIGURAS
2.15 Grano de adaptación a nivel de pı́xel en el sistema ConnecTables . . . . . . . . . 29
2.16 Grano de adaptación a nivel de pı́xel en el sistema MindMap . . . . . . . . . . . 29
2.17 Grano de recuperación a nivel de tarea en el sitio Web de Sedan-Bouillon . . . . 30
2.18 Grano de recuperación a nivel de acción fı́sica en el sistema MindMap . . . . . . 31
2.19 Adaptación a la plataforma y al usuario en el sitio Web de Sedan-Bouillon . . . 33
2.20 Adaptación a la plataforma y al usuario en el sistema Ubidraw . . . . . . . . . . 33
2.21 Adaptación a la plataforma en el sistema de control de calefacción . . . . . . . . 34
2.22 Adaptación a la plataforma en el sistema CamNote . . . . . . . . . . . . . . . . 34
2.23 Adaptación a la plataforma en el sistema Roomware . . . . . . . . . . . . . . . . 35
2.24 Adaptación a la plataforma en el sistema ConnecTables . . . . . . . . . . . . . . 35
2.25 Adaptación a la plataforma en el sistema MindMap . . . . . . . . . . . . . . . . 36
2.26 Meta-IU con negociación en el sitio Web de Sedan-Bouillon . . . . . . . . . . . . 38
3.1 Marco de Referencia Unificado para Interfaces de Usuario Multi-Objetivo . . . . 44
3.2 Estructura del modelo arquitectural de referencia CAMELEON-RT . . . . . . . 50
3.3 Marco conceptual de Plasticidad Explicita Colaborativa . . . . . . . . . . . . . . 55
3.4 Marco para la Adaptación de la Conciencia de Contexto en Despliegues Públicos 57
3.5 Diagrama de clases de la arquitectura Vistas de Contexto Hybreed . . . . . . . . 59
3.6 Marco Genérico de Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.7 Arquitectura conceptual del marco genérico de contexto . . . . . . . . . . . . . . 64
4.1 Escenarios y aplicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.2 Uso de las palabras deı́cticas “in this paragraph” (en la forma de una liga de
hipertexto) por parte de Isaac en la herramienta de la mensajerı́a instantánea
para referirse a un párrafo en el editor colaborativo . . . . . . . . . . . . . . . . 82
4.3 Uso de las palabras deı́cticas “in this diagram” (en la forma de una liga de hipertexto) por parte de Alice en la herramienta de la mensajerı́a instantánea para
referirse a la Fig. 1 del pizarrón multi-usuario . . . . . . . . . . . . . . . . . . . 83
4.4 Se sugiere a Sandy e Isaac seguir la conversación de Alice y Jenny porque ellas
están modificando la figura referenciada por el párrafo que ellos están modificando 84
ÍNDICE DE FIGURAS
xiii
4.5 Se sugiere a Alice y Jenny seguir la conversación de Sandy e Isaac porque ellos
están reescribiendo el párrafo que refiere a la figura que ellas están modificando . 85
4.6 Elección de participantes y sus roles en la creación del mapa mental . . . . . . . 93
4.7 Vista del mapa mental cuando el colaborador asume el rol de revisor
. . . . . . 94
4.8 Vista del mapa mental cuando el colaborador asume el rol de autor . . . . . . . 95
4.9 Adaptabilidad de la interfaz de usuario del editor de mapas mentales con base
en la configuración de grupo y las dimensiones de la pantalla de despliegue . . . 96
4.10 Vista detallada en los dispositivos móviles de los colaboradores distribuidos . . . 97
4.11 Disponibilidad y medios de contacto al inicio de la sesión colaborativa. . . . . . 107
4.12 Disponibilidad y medios de contacto de Sandy, Isaac y Alice una vez que Sandy
ha cambiado su actividad. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
4.13 IU del administrador de contenidos . . . . . . . . . . . . . . . . . . . . . . . . . 116
4.14 Adaptabilidad de la interfaz de usuario de la herramienta de votación de acuerdo
a la ubicación del grupo y al rol de votantes . . . . . . . . . . . . . . . . . . . . 123
4.15 Opciones establecidas por el colaborador proponente en el pizarrón blanco interactivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
4.16 Adaptabilidad de los resultados de votación de acuerdo a la localización de los
votantes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
5.1 Contexto de uso de los sistemas colaborativos . . . . . . . . . . . . . . . . . . . 131
5.2 Diagrama de clases del observador . . . . . . . . . . . . . . . . . . . . . . . . . . 134
5.3 Mecanismo para determinar entre dos colaboradores su similaridad de actvidades, la disponibilidad y los medios de contacto . . . . . . . . . . . . . . . . . . 138
5.4 Mecanismo para ocultar, sustituir o mostrar funcionalidades y/o componentes . 144
5.5 Creación de hiperligas desde la mensajerı́a instantánea . . . . . . . . . . . . . . 145
5.6 Visualización de documentos en forma de árbol . . . . . . . . . . . . . . . . . . 147
5.7 Mecanismo de tipos de trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
5.8 Capas del marco XARE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
xiv
ÍNDICE DE FIGURAS
Lista de Tablas
2.1 Entidades contempladas por los sistemas analizados . . . . . . . . . . . . . . . . 40
2.2 Variables contextuales de los sistemas analizados . . . . . . . . . . . . . . . . . . 41
3.1 Herramientas de ejemplo para el marco RUIUM-O . . . . . . . . . . . . . . . . . 48
3.2 Modelos conceptuales e implementación de los marcos estudiados . . . . . . . . 66
3.3 Análisis de los marcos con relación al contexto de uso
. . . . . . . . . . . . . . 68
3.4 Análisis de adaptación y contexto en los marcos presentados . . . . . . . . . . . 71
5.1 Similaridad entre las actividades de dos colaboradores . . . . . . . . . . . . . . . 139
5.2 Estado de disponibilidad del colaborador observado respecto a un colaborador
observador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
5.3 Proximidad lógica entre dos colaboradores dentro del espacio compartido . . . . 148
5.4 Sugerencia para llevar a cabo cuatro escenarios . . . . . . . . . . . . . . . . . . . 154
xv
xvi
LISTA DE TABLAS
Capı́tulo 1
Introducción
1.1
Trabajo Cooperativo Asistido por Computadora
En 1984, el Trabajo Cooperativo Asistido por Computadora (TCAC) se vuelve un campo de
investigación durante un taller (workshop) organizado en Massachussets Institute of Technology.
Este campo de investigación busca comprender las caracterı́sticas del trabajo cooperativo, con el
fin de diseñar tecnologı́a computacional adecuada para soportarlo. Para lograr este fin, TCAC
reagrupa el conocimiento de una amplia gama de disciplinas, e.g., la psicologı́a, la sociologı́a,
la informática y las comunicaciones, que tienen diferentes intereses de acuerdo con su campo
de estudio.
Un análisis histórico muestra que estas disciplinas evolucionaron separadamente durante la
primera década de la existencia de TCAC. Ası́, los computólogos se centraron en los principios
de diseño y en las estrategias de implementación de sistemas colaborativos, mientras que los
psicólogos y sociólogos se interesaron en el estudio de grupos de colaboración sin importar si
disponı́an o no de soporte tecnológico. Sin embargo, estas disciplinas son más conexas de lo que
parecen [Dourish, 1996]. De hecho, los principios de diseño y las estrategias de implementación
tienen un impacto significativo en la forma de trabajo adoptada por los colaboradores.
Dentro de una organización, se puede distinguir tres tipos de procesos cooperativos conforme a los cuales se han diseñado [Yongwu and Haake, 1999] diferentes tipos de aplicaciones
y herramientas colaborativas:
• la coordinación se refiere a que una acción individual da significado a las acciones de
otros, las cuales a su vez contribuyen a la realización de dicha acción individual para
lograr una meta final. La coordinación requiere de la sincronización de las personas y
acciones, ası́ como de la coherencia de las acciones individuales con respecto al proceso
completo;
• la colaboración es un proceso donde las personas trabajan conjuntamente en la eje1
2
Introducción
cución de una cierta actividad para crear un producto final. Al término del proceso, la
contribución individual no queda aislada, ya que el resultado final es mayor que la suma
de todas las contribuciones individuales (sinergia). Por lo tanto, la comprensión colectiva
de los objetivos y del conocimiento compartido es un factor fundamental;
• la decisión conjunta se refiere a que las personas contribuyen a tomar colectivamente
una decisión. La consideración del estatus en el contexto de la decisión conjunta es relevante, i.e., todos los participantes pueden tener la misma posición social en el proceso de
decisión o pueden hacer sus contribuciones con base en su rol especı́fico. La credibilidad,
el conocimiento compartido y la comprensión colectiva también son factores crı́ticos en
este contexto.
Para efectuar una tarea especı́fica (e.g., producción conjunta de documentos) es necesario
realizar algunas combinaciones de estos procesos cooperativos, requiriendo un mayor o menor
grado de conocimiento compartido o de sincronización.
Las situaciones más frecuentes en un trabajo cooperativo corresponden a la co-localización,
co-acceso, co-recomendación y co-depedencia. Por ejemplo, mientras los miembros de un grupo
trabajan en una sala de juntas (co-localización), ellos pueden acceder y manipular los mismos
documentos (co-acceso) y señalar información relevante (co-recomendación), de manera que las
tareas en las que estos colaboradores estén inmersos son dependientes de dichos documentos
(co-dependencia).
La co-localización ocurre cuando dos o más personas, objetos o dispositivos están fı́sica o
virtualmente cercanos unos de otros. El co-acceso denota la situación en donde varias personas
accedan al mismo objeto (un documento o un dibujo); la co-recomendación denota la situación
en la que las acciones explicitas o implı́citas de los colaboradores son usadas para sugerir
información útil en la realización de sus tareas comunes. Finalmente, la co-dependencia se
refiere a la relación existente entre varias tareas, objetos y usuarios [Haake et al., 2010].
Durante la última década, se han realizado grandes inversiones en aplicaciones cooperativas
tanto en el sector público como en el sector privado. Muchas de estas aplicaciones han sido
exitosas, e.g., Lotus Notes de IBM y PoliTeam [Sohlenkamp et al., 2000], pero algunas han sido
totalmente lo contrario. Existen varias razones que han conducido al fracaso de algunas de estas
aplicaciones, sin embargo se pueden mencionar al menos tres causas principales [Grudin, 1988]:
1) la disparidad entre las personas que hacen el trabajo y aquellas que obtienen los beneficios;
2) la falta de intuición para administrar aplicaciones cooperativas; y 3) la dificultad extrema
para evaluar estas aplicaciones.
Tradicionalmente, el campo del TCAC ha dado lugar a aplicaciones costosas que han sido
implantadas en el Intranet de una compañı́a o en Internet. La tendencia actual de muchas
aplicaciones colaborativas es hacia Internet, ya que es un medio relativamente accesible en
cualquier lugar y en cualquier momento. De esta manera, resulta más fácil para las personas
comunicar, coordinar y realizar tareas colaborativas independientemente de las fronteras globales. Sin embargo, la principal desventaja de Internet como medio para implantar aplicaciones
Capı́tulo 1
3
colaborativas es el riesgo de seguridad, razón por la cual muchas compañı́as prefieren las soluciones en Intranet. A pesar de esta desventaja, Internet ofrece masivas oportunidades a nuevos
vendedores de aplicaciones colaborativas para comercializar y poner a disposición de la gente
sus versiones libres (e.g., Dropbox).
1.2
Interacción Humano-Computadora
Este campo de investigación se interesa en el diseño, la evaluación y la implementación de
sistemas de cómputo interactivos para uso humano, ası́ como en el estudio de los fenómenos
principales que los rodean [Raskin, 1994]. Los principales objetivos del campo de Interacción
Humano-Computadora (IHM) son: 1) mejorar las interacciones entre usuarios y computadoras,
y 2) lograr que éstas últimas se vuelvan cada vez más usables y receptivas a las necesidades del
usuario. Particularmente, este campo de investigación se centra en el estudio y desarrollo de:
1) metodologı́as y procesos para diseñar interfaces bajo restricciones dadas (usuarios y tareas),
pero que aseguren una caracterı́stica deseada, e.g., facilidad de aprendizaje o eficiencia de uso;
2) métodos para implementar interfaces, e.g., cajas de herramientas, librerı́as y algoritmos
eficientes; 3) técnicas para evaluar y comparar interfaces; 4) nuevas interfaces y técnicas de
interacción, ası́ como 5) modelos de descripción/predicción y teorı́as de interacción.
Un objetivo a largo plazo de IHM es diseñar sistemas que minimicen la barrera entre el modelo
cognitivo humano de lo que el usuario quiere realizar y la comprensión de la tarea del usuario por
parte de la computadora. A este respecto, las investigaciones en IHM se centran en desarrollar
nuevas metodologı́as de diseño, en experimentar con nuevos dispositivos de hardware, en crear
prototipos de sistemas de software nuevos, en explorar nuevos paradigmas de interacción y en
desarrollar modelos y teorı́as de interacción.
Diversas metodologı́as que resumen técnicas para el diseño de interfaces de usuarios han
emergido desde la identificación de este campo de investigación en 1980. La mayorı́a de
las metodologı́as de diseño provienen de un modelo que describe cómo interactúan usuarios,
diseñadores y sistemas.
Las primeras metodologı́as trataron los procesos cognitivos de los usuarios como predecibles
y cuantificables. Asimismo, estas metodologı́as motivaron a los diseñadores de interfaces de
usuario a observar los resultados de la ciencia cognitiva en áreas como “memoria” y “atención”.
Por el contrario, los modelos modernos se enfocan en una constante realimentación y conversación entre usuarios, diseñadores e ingenieros y promueven que los sistemas estén a la merced
de los tipos de experiencias que los usuarios quieren tener, en vez de poner las experiencias del
usuario a la merced del sistema.
El diseño centrado en el usuario es una filosofı́a de diseño moderna y ampliamente practicada,
cuya base se centra en la idea de que los usuarios deben ser el “centro del escenario” en el diseño
de cualquier sistema de cómputo. Usuarios, diseñadores y técnicos trabajan conjuntamente
para articular las preferencias, necesidades y limitaciones de los usuarios y para desarrollar
4
Introducción
sistemas que satisfagan sus requerimientos. Con frecuencia, los proyectos de diseño centrados
en el usuario son influenciados por estudios etnográficos de los entornos donde tendrá lugar la
interacción usuario-sistema.
Modalidad y multimodalidad
El término multimodalidad proviene de la palabra modalidad. En psicologı́a cognitiva, la
modalidad [Vanderdonckt, et al., 2008] denota un sentido humano (vista, tacto, oı́do, olfato y
gusto). Otros autores definen la modalidad como un modo de comunicación dependiente de los
sentidos humanos o de los dispositivos de entrada. Existen algunas modalidades que intentan
ser parecidas a los sentidos humanos, e.g., cámara-vista, sensor táctil-tacto, micrófono-oı́do,
olfativos-olor e incluso el gusto [Legin et al., 2005, Jaimes and Sebe, 2005]. Otras corresponden
a los dispositivos de entrada tradicionales, e.g., teclado, ratón y pantalla táctil.
En el ámbito computacional, el término de modalidad permite representar información
usando un medio fı́sico y una forma de representación. En particular, la forma de representación
admite que las personas utilicen diferentes modalidades para representar la información en el
mismo medio fı́sico, por lo tanto se usa el mismo sentido humano, e.g., considere la luz como un
medio fı́sico y la visión como un sentido. Se usa la visión para percibir diferentes modalidades
de información, e.g., texto, imágenes y expresiones faciales [Vanderdonckt, et al., 2008].
Una definición formal de modalidad se muestra en la expresión (1.1), en donde la modalidad (M) es la pareja integrada por un lenguaje de interacción (L) y un dispositivo fı́sico (d)
[Vanderdonckt, et al., 2008]:
M ::=< L, d >
(1.1)
Un lenguaje de interacción (L) define un conjunto de expresiones bien formadas (i.e., una
cadena de sı́mbolos) que transmiten un significado . La generación de uno o varios sı́mbolos
resulta de las acciones efectuadas sobre los dispositivos fı́sicos. Un dispositivo fı́sico (d) es
un elemento de la plataforma anfitriona del sistema interactivo que se comporta como un
recurso de interacción, ya que adquiere (dispositivo de entrada) o entrega (dispositivo de salida)
información. Algunos ejemplos de modalidad se presentan a continuación:
• discurso=<pseudo-lenguaje natural NL, micrófono> (cf. Expresión 1.1), donde
discurso es una modalidad compuesta por un pseudo-lenguaje natural NL (lenguaje
de interacción) y un micrófono (dispositivo);
• escrito a máquina=<pseudo-lenguaje natural NL, teclado>, donde escrito a
máquina representa una modalidad conformada por un pseudo-lenguaje natural NL
(lenguaje de interacción) y un teclado (dispositivo);
• discurso=<pseudo-lenguaje natural NL, altavoz>, donde discurso es una modalidad que contiene un pseudo-lenguaje natural NL (lenguaje de interacción) y un
altavoz (dispositivo);
Capı́tulo 1
5
• gráfico=<lenguaje gráfico GL, pantalla>, donde gráfico representa una modalidad, lenguaje gráfico GL corresponde al lenguaje de interacción y pantalla concierne
al dispositivo.
• manipulación directa=<lenguaje de manipulación ML,
ratón>,
donde
manipulación directa corresponde a una modalidad, lenguaje de manipulación ML
representa el lenguaje de interacción y finalmente, ratón denota al dispositivo.
Una modalidad puede desempeñar el papel de un dispositivo de entrada para producir frases
de un lenguaje de interacción. Por ejemplo, las palabras de una frase de un pseudo-lenguaje
natural pueden ser producidas por la selección de palabras desde un menú flotante utilizando un
ratón. En este caso, el teclado es remplazado por la modalidad <selección desde menú flotante,
ratón>. La definición general de una modalidad se refleja en la expresión (1.2), en donde L es un
lenguaje de interacción, d es un dispositivo y M es una modalidad [Vanderdonckt, et al., 2008]:
M ::=< L, d > | < L, M >
(1.2)
La comunidad cientı́fica ha debatido por varios años la definición de multimodalidad, ası́
como sus usos, sin llegar a un consenso. En el ámbito de IHM, la multimodalidad ha sido
definida de varias maneras, algunas de ellas se citan a continuación:
• es la interacción de múltiples técnicas que involucran varios sentidos humanos simultáneamente [Vanderdonckt, et al., 2008];
• responde a las entradas de más de una modalidad o canal de comunicación, e.g., discursos,
gestos y escritura [Jaimes and Sebe, 2005];
• coordina el proceso de entradas multimodales (e.g., el habla, el tacto, las gesticulaciones
manuales, la mirada, los movimientos de cabeza y el cuerpo) con sistemas multimedia de
salida [Oviatt, 1999].
Los sistemas multimodales se diferencian en la forma de combinar las modalidades, de manera
que existen dos tipos de sistemas multimodales: de entrada o de salida. Un sistema multimodal de entrada combina de manera coordinada dos o más modos de entradas con un sistema multimedia de salida. Por ejemplo, el sistema MultimodaliXML [Stanciulescu et al., 2005]
permite que el usuario ingrese información al sistema a través de una interacción gráfica, vocal y/o táctil. Un sistema multimodal de salida presenta la información combinando dos
o más modalidades de comunicación, e.g., el sistema de neurocirugı́a llamado The Assisted
Neuro-surgery System utiliza gráficos y audio [Vanderdonckt, et al., 2008].
Las modalidades de entrada se dividen en dos grupos (cf. Figura 1.1): el primero está basado
en los sentidos humanos (e.g., vista, tacto y oı́do) y el segundo corresponde a los dispositivos
6
Introducción
de entrada (e.g., ratón y teclado). La multimodalidad sirve como entrada a las aplicaciones por
medio de las interfaces de usuario. Las aplicaciones que utilizan la multimodalidad conciernen
principalmente a las de colaboración remota, reuniones, entre otras [Jaimes and Sebe, 2005].
Figura 1.1: Visión general de la interacción multimodal mediante un enfoque centrado en el
usuario
1.3
Contexto de investigación
Este tema de tesis doctoral se inscribe en el campo de investigación del Trabajo Cooperativo
Asistido por Computadora (TCAC). Como se mencioná en la sección 1.1, este campo multidisciplinario estudia tanto los aspectos sociales de las actividades individuales y colectivas,
como los aspectos tecnológicos de la información y de las comunicaciones, con el fin de asistir
la colaboración entre personas potencialmente distribuidas [Dourish, 1996].
En relación con el carácter multidisciplinario de TCAC, este proyecto de investigación
toma principalmente la perspectiva de la informática y de las comunicaciones, con el objeto
de modelar, diseñar e implementar una infraestructura que facilite el desarrollo de sistemas
cooperativos (cf. Figura 1.2). Estos sistemas proveen espacios de trabajo que permiten a
los colaboradores comunicarse entre si, producir conjuntamente información compartida y
coordinar sus actividades, aún cuando no puedan reunirse fı́sicamente en el mismo lugar y/o
al mismo tiempo.
TCAC contempla varios dominios de aplicación. Particularmente, este proyecto de
tesis abordará el dominio de aplicación de la producción cooperativa de documentos.
Aún si numerosos trabajos de investigación se han consagrado al estudio de este dominio de aplicación, e.g., [Buzzi et al., 2010], [Pinelle et al, 2008], [Secretan et al., 2008],
[Cerratto and Rodrı́guez, 2002], [Paredes and Fonseca, 2010] y [Wei et al., 2009], la producción
Capı́tulo 1
7
Figura 1.2: Contexto de investigación de este proyecto doctoral
cooperativa de documentos es un problema recurrente. Los sistemas cooperativos que soportan
este dominio de aplicación deben permitir a grupos de coautores planificar sus tareas, ası́ como
producir, revisar y comentar sus contribuciones. Aunque este dominio de aplicación haga intervenir grupos consecuentes de coautores, algunos estudios sociológicos muestran que se trata
de pequeños grupos que varı́an entre dos y cinco individuos [Beck, 1993].
El fenómeno de la globalización no solamente ha dado lugar a la distribución de organizaciones, sino también a la colaboración entre organizaciones localizadas en diferentes partes
del mundo. En consecuencia, las personas necesitan trabajar conjuntamente a pesar de la
distancia y de la eventual restricción de poder reunirse al mismo tiempo a causa de las diferencias horarias [Gall and Hauck, 1997]. En respuesta a este requerimiento, este proyecto de
investigación pretende proveer soportes para la interacción distribuida mediante dispositivos de
cómputo diversos, e.g., pizarrones digitales, PCs, PDAs y smartphones.
Por otra parte, la mayorı́a de las herramientas actuales implı́citamente asumen que su interfaz de usuario se confina en un solo dispositivo de cómputo, lo cual implica que el usuario
se vuelva sedentario cuando interactúa con su PC, mediante dispositivos de E/S tradicionales,
e.g., teclado, ratón y monitor. Sin embargo, la creciente proliferación de dispositivos heterogéneos y el progreso de las redes de comunicación permiten imaginar al usuario como un
“ente que evoluciona en un entorno variado y que utiliza, de manera oportunista, dispositivos
fijos y móviles con el fin de satisfacer sus necesidades en cualquier lugar donde se encuentre”
[Calvary et al., 2006].
Un sistema interactivo evidentemente no puede ofrecer la misma presentación en todo tipo de
dispositivo. Sin embargo, el desarrollo separado de sistemas adaptados a cada contexto de uso
no sólo es extremadamente costoso, en términos de desarrollo y mantenimiento, sino también
puede dar lugar a comportamientos incoherentes. Algunas posibles consecuencias podrı́an ser
la sub-utilización de los sistemas y el costo requerido para mantener la consistencia de versiones
8
Introducción
en múltiples dispositivos heterogéneos. La propiedad de “plasticidad” pretende hacer frente a
estos problemas (cf. Figura 1.2).
La plasticidad es la capacidad de los sistemas interactivos para adaptarse a un conjunto
de contextos de uso, garantizando en todo momento un conjunto de criterios de calidad, e.g.,
la usabilidad y la continuidad de interacción [Calvary et al., 2004]. El término de plasticidad
[Thevenin and Coutaz, 1999] fue introducido, a finales de los noventas, en el dominio de los
sistemas interactivos mono-usuario, en respuesta a la creciente diversidad de dispositivos de
cómputo. Este término se inspira en la propiedad de los materiales que les permite expandirse
y contraerse, sin romperse, bajo restricciones naturales. La plasticidad puede repercutir tanto
en los componentes de la interfaz de usuario como en el núcleo funcional del sistema, tal como
sucede con el descubrimiento de servicios, e.g., si un usuario se movió hacia un lugar donde
está disponible un nuevo servicio, éste aparecerá en su PDA. En este ejemplo, la interfaz de
usuario se remodela, con el fin de incorporar este nuevo servicio y de soportar una interacción
oportunista.
1.4
Planteamiento del problema
Vanderdonckt et al. caracterizan el espacio del problema de las interfaces de usuario plásticas
mediante siete dimensiones [Vanderdonckt et al., 2008]: 1) percutores de plasticidad, 2) granularidad de los componentes de la interfaz de usuario, 3) granularidad del estado de recuperación,
4) despliegue de la interfaz de usuario, 5) contexto de uso, 6) meta-interfaz de usuario y 7) espacio tecnológico. Sin embargo, hoy en dı́a, no existen sistemas mono-usuario ni colaborativos
que comprendan estas siete dimensiones (cf. Capı́tulo 2).
A pesar de que las compañı́as tecnológicas han puesto a disposición de los usuarios una variedad cada vez más amplia de dispositivos, los cuales difieren en sus caracterı́sticas fı́sicas (e.g.,
tamaño de pantalla, capacidad de memoria e inclusión de cámaras, altavoz y teclado) y lógicas
(e.g., diferentes plataformas y librerı́as), en la actualidad no existen sistemas colaborativos
plásticos que hagan frente a esta heterogeneidad.
Los pocos sistemas colaborativos plásticos del estado del arte, e.g., ConnecTables
[Tandler et al., 2001] y MindMap [Lucero et al., 2010], han sido desarrolldos “a la medida”, i.e.,
funcionan para dispositivos con caracterı́sticas idénticas o similares. Aunque, dichos sistemas
ofrecen algunas propiedades plásticas, e.g., adaptar el área de trabajo al detectar dos tablets
unidas fı́sicamente, el problema de desarrollar sistemas “a la medida” aparece al momento de
querer agregar una nueva propiedad plástica, ya que esta puede requerir modificaciones en gran
parte de dichos sistemas. La mejor opción para crear un sistema colaborativo plástico serı́a el
uso de un marco de desarrollo (framework) que ofrezca una gama de opciones de adaptación
pre-definidas, pero extensibles.
Si se hace un recuento de los marcos para sistemas mono-usuario plásticos, que están
disponibles a los desarrolladores, podemos observar que aunque todos adordan los elementos
Capı́tulo 1
9
del contexto de uso (i.e., usuario, entorno y plataforma), sólo unos cuantos consideran alguna
forma de adaptación (i.e., remodelación, migración o redistribución). Por lo tanto, se puede
constatar que estos marcos no solo están limitados en cuanto al número ofertado, sino también
respecto a las dimensiones plásticas consideradas.
Los marcos que pretenden facilitar el desarrollo de Sistemas Colaborativos Plásticos (SCP)
sólo se preocupan por cubrir algunos elementos del contexto de uso. Sin embargo, una de las
principales limitaciones de dichos marcos reside en el uso del concepto de “contexto de uso”, tal
como fue definido para sistemas mono-usuario. Por obvias razones, dicho concepto no considera
los requerimientos propios de los sistemas colaborativos como, por ejemplo, la intervención de
múltiples usuarios, el uso compartido de recursos fı́sicos y virtuales y la provisión de información
de conciencia de grupo para conformar un entorno común.
Asimismo, la mayorı́a de los marcos SCP ofrecen únicamente un soporte conceptual, el cual
resulta difı́cil de entender y aplicar durante las fases de diseño e implementación. Los pocos
marcos que proveen un soporte de implementación sólo abordan de manera muy limitada la
dimensión del contexto de uso, dejando completamente de lado las otras seis dimensiones del
espacio del problema de las interfaces de usuario plásticas.
Ninguno de los marcos SCP satisface la necesidad ineludible de recuperación de información,
cuando esta se pierde al momento de pasar de un contexto de uso a otro. La información no
recuperada es de vital importancia, puesto que puede ser el resultado de varias horas de trabajo.
La mayorı́a de los marcos SCP sólo ofrece un percutor de plasticidad que actúa de manera
estática sobre una granularidad fija de la interfaz de usuario. Este único percutor permite
que algunos componentes de la interfaz de usuario se remodelen, se redistribuyan en varios
dispositivos o bien migren de un dispositivo a otro para adaptarse al nuevo contexto de uso.
Además, dicho percutor actúa sobre una granularidad fija de la interfaz de usuario, i.e., a nivel
de interactor (e.g., icono), a nivel de tarea (e.g., una ventana de impresión) o bien a nivel de la
interfaz de usuario completa (e.g., transformación de una forma textual a una gráfica). Dado
que dichos marcos SCP no ofrecen todas las opciones resultantes de la combinación de estas
dos dimensiones (i.e., percutores de plasticidad y granularidades de la interfaz de usuario), las
posibles interfaces de usuario son generadas de manera estática.
Finalmente, algunos marcos SCP exploran la meta-interfaz de usuario de manera muy limitada ya que dejan, como cuestiones abiertas, las meta-interfaces de usuario plásticas y sin
negociación, i.e., aquellas en las que no se requiere la intervención del usuario en el proceso de
adaptación, dado que el sistema es capaz de adaptarse de manera autónoma.
10
Introducción
1.5
Objetivos del proyecto
Objetivo general
Analizar los requerimientos y los posibles enfoques de solución propuestos en el estado del
arte para dotar a los sistemas cooperativos de propiedades plásticas. A partir de este análisis
se proponen soluciones, tanto a nivel teórico como a nivel práctico, que faciliten el desarrollo
de sistemas capaces de solucionar algunos problemas de las interfaces de usuario plásticas
multimodales.
Objetivos particulares
1. Redefinir el concepto de “contexto de uso” propuesto en el dominio de los sistemas monousuario para adaptarlo al dominio de los sistemas cooperativos.
2. Desarrollar un modelo conceptual de plasticidad que sirva como instrumento de referencia
para ayudar a los desarrolladores en el proceso de construcción de sistemas cooperativos
plásticos.
3. Con base en los conceptos, principios y mecanismos propuestos en el modelo conceptual
de plasticidad, se pretende diseñar un marco de desarrollo (framework) que facilite:
(a) la adaptación de sistemas cooperativos a diferentes contextos de uso que contemplen
todos o algunos elementos (usuario, entorno y plataforma);
(b) la creación de meta-interfaces que involucren a los usuarios en el proceso de
adaptación como observadores o como entes activos, según convenga;
(c) la remodelación y redistribución de la interfaz de usuario de estos sistemas;
(d) el uso de diferentes granularidades de adaptación (total, espacio de trabajo, interactor y pixel), y
(e) la recuperación del estado de dichos sistemas a nivel sesión, tarea y acción.
4. Validar el marco propuesto mediante el desarrollo de algunas aplicaciones de edición
cooperativa para poner en evidencia sus alcances y limitaciones.
1.6
Organización del documento
La organización de este documento se resume en la figura 1.3. El capı́tulo 1 corresponde a esta
introducción en donde se dio un panorama general de la problemática a resolver, ası́ como los
objetivos a cumplir en este proyecto de investigación.
Capı́tulo 1
11
Introducción
Capítulo 1
Estado del arte
Capítulo 2
Capítulo 3
Contribuciones
Capítulo 5
Capítulo 4
Validación
Capítulo 6
Conclusiones
Capítulo 7
Figura 1.3: Organización del documento
Tanto el capı́tulo 2 como el capı́tulo 3 presentan el estado del arte. En particular, el capı́tulo
2 describe las dimensiones del espacio del problema de las interfaces de usuario plásticas, las
cuales han sido ejemplificadas mediante ocho aplicaciones representativas. Dado que dichas
dimensiones fueron identificadas en el dominio de los sistemas mono-usuario, en el capı́tulo 3
se detallan los marcos más relevantes para el desarrollo de este tipo de sistemas. Asimismo,
en el capı́tulo 3, se describen los principales marcos de desarrollo para sistemas colaborativos
plásticos, con la finalidad de analizar los avances logrados en ambas vertientes.
El marco XARE (conteXt-Aware groupwaRE), propuesto en tesis, pretende orientar a los
desarrolladores en la creación de sistemas cooperativos plásticos. El análisis de este marco
se describe en el capı́tulo 4, el cual inicia presentando una definición de los elementos que
conforman el contexto de uso en sistemas cooperativos. A continuación, se proponen varios
escenarios que ponen en evidencia algunas dimensiones del espacio del problema de las interfaces
12
Introducción
de usuario plásticas. La mayorı́a de estos escenarios son ejemplificados mediante aplicaciones.
Algunas de estas son prototipos que sirvieron de base para diseñar e implementar el marco
propuesto.
En el capı́tulo 5, se expone primeramente la reconceptualización del contexto de uso para
el dominio de los sistemas cooperativos. Para realizar dicha reconceptualización, se hizo
uso del patrón de diseño Decorador, el cual permite a los desarrolladores añadir y suprimir
dinámicamente contextos de uso en un sistema cooperativo. También se incluyen los diagramas
de clases generados a partir de algunos escenarios. La mayorı́a de las propuestas de adaptación
al contexto, que se ponen en evidencia en dichos escenarios, han sido concretizadas en forma
de mecanismos. Finalmente, se describen las capas que conforman el marco XARE.
El capı́tulo 6 presenta la validación del marco XARE. En particular, se define la API que
permite la comunicación entre las capas de dicho marco y entre los componentes de cada capa.
Para hacer más claro el funcionamiento de dicho marco, se muestra el flujo de información para
algunos de los escenarios analizados, en especı́fico para aquellos que han sido explorados con
mayor profundidad.
En el capı́tulo 7, se presentan las conclusiones derivadas del trabajo desarrollado, ası́ como
algunas ideas de trabajo a futuro que ayudarı́an a mejorar el marco XARE.
Capı́tulo 2
Interfaces de usuario plásticas en
sistemas interactivos
En el presente capı́tulo se estudian las interfaces de usuario plásticas, las cuales tienen origen en
el área de Interacción Humano-Computadora. El análisis realizado en este apartado considera
varias dimensiones que podrı́an ser tratadas cuando se implementa la propiedad de plasticidad
en sistemas interactivos, e.g., informar o consultar al usuario acerca de los cambios necesarios
para adaptarse al nuevo contexto de uso. Las dimensiones a considerar se han dividido en
dos grandes partes que se consideran relevantes para este trabajo de investigación. La primera
parte estudia las siete dimensiones de las interfaces plásticas propuestas en el dominio de
los sistemas interactivos mono-usuario (cf. sección 2.1-2.8). La segunda parte analiza las
dimensiones desarrolladas en el ámbito de los sistemas conscientes de contexto (cf. sección
2.9). Para ejemplificar dichas dimensiones, se consideran varios sistemas interactivos, los cuales
están enfocados en apoyar el trabajo individual o el grupal. Finalmente, se presentan las
conclusiones de este capı́tulo (cf. sección 2.10).
2.1
Problemas encontrados en las interfaces de usuario
plásticas multi-modales
Como se mencionó en el capı́tulo 1, la interfaz de usuario de un sistema interactivo no puede ser
la misma para un dispositivo pequeño (e.g., una PDA) que para uno grande (e.g., un pizarrón
electrónico); el problema se agudiza si se consideran las demás caracterı́sticas de hardware (e.g.,
capacidades de procesamiento, almacenamiento y comunicación) y software (e.g., sistema operativo y lenguajes de programación soportados) de dicho dispositivo. Por lo tanto, la ejecución
de un sistema interactivo en diferentes dispositivos genera varios inconvenientes que pueden
convertirse en un problema de grandes dimensiones al agregar otras variantes, e.g., habilitar
o deshabilitar funcionalidades a un usuario, dependiendo de su ubicación virtual dentro de un
13
14
Interfaces de usuario plásticas en sistemas interactivos
documento.
Vanderdonckt et al. han identificado las siguientes siete dimensiones para adaptar una interfaz de usuario (IU) a cambios en el contexto de uso (cf. Figura 2.1) [Vanderdonckt, et al., 2008]:
• Percutores de plasticidad: permiten cambiar la presentación de la IU mediante remodelación, redistribución y migración de componentes;
• Granularidad de la IU: representa la unidad más pequeña de la IU que puede ser
adaptada; la granularidad puede ser a nivel de pı́xel, de interactor (e.g., un ı́cono), de
espacio de trabajo o de aplicación;
• Granularidad de recuperación del estado: se refiere al estado del sistema, después
de la adaptación; la recuperación del sistema puede ser a nivel de sesión, de tarea o de
acción;
• Despliegue de la IU: indica la forma en que la IU lleva a acabo la adaptación; esta
dimensión contempla dos formas: estática o dinámica;
• Contexto de uso: plantea las causas que provocan la adaptación del sistema; los factores
para realizar la adaptación son provocados por cambios en el usuario, en el entorno o en
la plataforma;
• Espacio tecnológico (ET): caracteriza el grado de heterogeneidad técnica soportada
por el sistema; el espacio puede ser intra-ET, inter-ET y multi-ET;
• Meta-Interfaz de Usuario (Meta-IU): permite a los usuarios controlar y evaluar el
proceso de adaptación; la meta-IU puede ser implementada con negociación o sin negociación; otra cuestión importante, la cual sigue abierta, es aplicar plasticidad a una
meta-IU para que pueda adaptarse a los cambios contextuales.
Las dimensiones de la Figura 2.1 serán ejemplificadas mediante ocho sistemas interactivos,
los cuales serán descritos de forma concisa a continuación.
El sitio Web Sedan-Bouillon, que promueve las ciudades de Sedan y Bouillon, tiene como
caracterı́stica primordial permitir a los usuarios participar en la redistribución entre una PC y
una PDA de la página principal para facilitar la navegación [Balme et al., 2005].
El sistema de control de calefacción permite al usuario controlar la temperatura de algunos
cuartos de su casa, usando dispositivos heterogéneos, e.g., PDA, PC, teléfono móvil y reloj de
pulso [Coutaz and Calvary, 2008].
El sistema FlexClock no solo provee diecisiete configuraciones predefinidas de los componentes
de la fecha y de la hora, sino también permite adaptar tales componentes al tamaño de la
ventana [Grolaux et al,. 2002].
Capı́tulo 2
15
Figura 2.1: Espacio del problema de las interfaces de usuario plásticas multimodales
El sistema Ubidraw permite tanto crear dibujos vectoriales como adaptar su IU al tamaño
de la ventana dependiendo de la tarea actual (e.g., el último icono que fue seleccionado), la
frecuencia de la tarea (e.g., la cantidad de clics sobre cada ı́cono) y la preferencia del usuario
por una tarea (e.g., la posición del icono dentro de las preferencias/necesidades del usuario)
[Vanderdonckt and González-Calleros, 2008].
El sistema CamNote está compuesto de dos espacios de trabajo: uno contiene un visor de
diapositivas y el otro comprende tanto un panel de control para navegar entre las diapositivas
como un editor de notas. Ambos espacios de trabajo despliegan como fondo el video del
usuario en tiempo real. La caracterı́stica principal de CamNote es dividir dinámicamente su
IU entre dispositivos heterogéneos (PC y pocket PC) al detectar la presencia de una pocket PC)
[Demeure et al., 2005].
A diferencia de los anteriores sistemas interactivos mono-usuario, los siguientes sistemas se
enfocan en el trabajo grupal, cuyos miembros están colocalizados. El sistema Roomware agrega
capacidades de cómputo y comunicación a objetos reales, e.g., paredes, mesas y sillones, con la
finalidad de explorar nuevas formas de interacción entre los colaboradores [Prante et al., 2004].
Los componentes de interacción de Roomware son tres: 1) Dynawall, 2) InteracTable y 3)
CommChair. Dynawall está compuesto por tres pizarrones electrónicos, empotrados en la
16
pared, que forman un dispositivo largo y sensible al contacto. InteracTable es una pantalla
sensible al contacto colocada en la parte superior de una mesa. Finalmente, CommChair
combina la movilidad y el confort de una silla con la funcionalidad de una computadora.
El sistema ConnecTables facilita la transición del trabajo individual al trabajo grupal (y
viceversa). Dicha transición se lleva a cabo cuando dos colaboradores unen sus tablets PC
para crear dinámicamente un espacio de trabajo compartido, donde los colaboradores pueden
arrastrar las imágenes desde una tablet hacia la otra [Tandler et al., 2001].
El último sistema a considerar es MindMap que sirve para crear, editar y visualizar mapas
mentales usando teléfonos celulares. La manera de utilizar estos dispositivos rompe con el
paradigma de uso personal. Los aparatos telefónicos pueden ser conectados de manera vertical
(alineados entre ellos) o de manera perpendicular (en forma de T). Una caracterı́stica importante de este sistema es el escalamiento del mapa mental mostrado en pantalla, i.e., cuando
el dispositivo está sobre la mesa, el mapa mental tiene una escala de 1:1; en cambio cuando
está en la mano del colaborador, la escala es menor de 1:1 con el objetivo de que el mapa sea
visualizado completamente en una única pantalla [Lucero et al., 2010].
2.2
Percutores de plasticidad
La adaptación del sistema al contexto de uso (plataforma, entorno o usuario) puede tomar
múltiples formas. En está sección se explica cómo percibe un usuario la adaptación del sistema.
La adaptación puede llevarse a cabo al aplicar uno o varios de los siguientes percutores de
plasticidad: remodelación, redistribución y migración de la IU [Coutaz and Calvary, 2008].
2.2.1
Remodelación
La remodelación de la IU denota cualquier reconfiguración que es perceptible al usuario y que
resulta de la aplicación de una o más transformaciones sobre toda o una parte de la IU. Las
transformaciones incluyen [Vanderdonckt, et al., 2008, Coutaz and Calvary, 2008]:
• Inserción de nuevos componentes: proporciona acceso a los nuevos servicios relevantes en el nuevo contexto de uso o situación, e.g., si existe más espacio disponible en la
pantalla se podrá exhibir más información útil;
• Eliminación de componentes: suprime componentes que sean irrelevantes en el nuevo
contexto de uso o situación, e.g., remover los componentes innecesarios de la IU para un
determinado rol;
• Sustitución de componentes: reemplaza algunos componentes por otros. La sustitución puede verse como la combinación de inserción y eliminación, e.g., conversión de
un menú fijo en uno flotante;
Capı́tulo 2
17
• Reorganización de los componentes: revisa la disposición y las dependencias temporales de los componentes. La reorganización puede resultar de la inserción, eliminación
o sustitución de componentes de la IU, e.g, la sustitución de un componente puede verse
al reducir una lista completa en una lista desplegable, si el usuario cambia de una PC a
una PDA. La reorganización puede afectar diversas partes de la IU, e.g., la reorganización
de una página Web puede afectar de manera independiente al estilo, a la disposición, al
contenido, a la estructura, a la navegación, ası́ como a la modalidad inicial de la página;
• Degradación: debido a un cambio de plataforma computacional se reorganiza la IU, la
cual pasa de una plataforma limitada a una aún más limitada, e.g., de una PC a un PDA
o de un screen phone tomada de un video1 a un teléfono móvil. La gradación ascendente
es el proceso inverso que consiste en mejorar la IU cuando el usuario cambia de una
plataforma limitada a una menos limitada.
La remodelación de una IU puede implicar cambios en el sistema de modalidades y/o cambios
en las caracterı́sticas CARE (Complementarity, Assignament, Redundancy and Equivalence)
[Vanderdonckt, et al., 2008] que son soportadas.
Las transformaciones pueden ser aplicadas a diferentes niveles de abstracción, los cuales se
describen a continuación [Vanderdonckt, et al., 2008, Calvary et al., 2006]:
• Intra-modal: los componentes de la IU que necesitan ser remodelados (IU fuente) se
redefinen en la misma modalidad, e.g., si la IU fuente es multi-modal, entonces la IU
objetivo también será multi-modal, i.e., la remodelación intra-modal no provoca ninguna
pérdida en las modalidades establecidas. En este caso, la modalidad se preserva, e.g., de
gráfico a gráfico;
• Inter-modal: los componentes de la IU fuente se redefinen en una modalidad diferente.
Esta transformación puede engendrar la pérdida o el aumento de una modalidad. Ası́,
una IU multi-modal puede ser convertida en una IU mono-modal o de manera inversa
(una IU mono-modal puede ser transformada en una IU multi-modal);
• Multi-modal: permite la combinación de transformaciones (intra- e inter- modal), e.g.,
la herramienta TERESA [Paterno et. al., 2008] utiliza la modalidad gráfica y vocal.
Dado que una modalidad está definida como M:= ≪ L, d ≫|≪ L, M ≫, en donde M es la
modalidad, L lenguaje de interacción y d un dispositivo fı́sico (cf. Sección 1.2), un cambio de
la modalidad puede resultar de [Vanderdonckt, et al., 2008]:
• Una substitución del dispositivo (a condición de que el nuevo dispositivo soporte el
lenguaje de interacción original);
1
Screen phone es un teléfono ubicado en una terminal. http://www.comtek-intl.com/screenphone.htm
18
• Una substitución del lenguaje de interacción (a condición de que el dispositivo original
permita el nuevo lenguaje de interacción);
• Un cambio radical del dispositivo y del lenguaje de interacción.
Analizando la remodelación en los sistemas de ejemplo, se puede observar que el sistema
de control de calefacción se reconfigura a nivel inter-modal, ya que la IU tanto de la PC
como de la PDA se clasifican en la modalidad gráfica (cf. Figura 2.2 a y b tomadas de
[Coutaz and Calvary, 2008]), mientras que la IU del teléfono móvil y del reloj pertenecen a
la modalidad textual (cf. Figura 2.2 c y d tomadas de [Coutaz and Calvary, 2008]). Todos los
demás sistemas son intra-modales porque sus componentes fuente se reconfiguran dentro de la
misma modalidad gráfica.
a) PC
b) PDA
d) Reloj digital
c) Teléfono móvil
Modalidad: gráfica
Modalidad: textual
Figura 2.2: Remodelación en el sistema de control de calefacción
2.2.2
Redistribución
La redistribución denota la reasignación de los componentes de la IU de un sistema a diversos dispositivos de interacción. Cuatro tipos de redistribución han sido identificados
[Calvary et al., 2006]:
1. De centralizada a centralizada: conserva el estado centralizado de la IU, e.g., migración total de la IU de una PC a una PDA;
Capı́tulo 2
19
2. De centralizada a distribuida: desmiembra la IU, e.g., repartición entre una PC y un
PDA;
3. De distribuida a centralizada: reconcentra la IU en una sola plataforma;
4. De distribuida a distribuida: cambia el estado de distribución de la IU.
Puesto que la IU puede estar distribuida, cada plataforma juega un rol especı́fico:
• Plataformas complementarias: cada una está encargada de un subconjunto de tareas
del usuario, y
• Plataformas totalmente equivalentes: permiten al usuario realizar una tarea en
diferentes plataformas, e.g., tanto en una PC como en una PDA, según su conveniencia.
Coutaz y Calvary [Coutaz and Calvary, 2008] definen la redistribución estática y dinámica.
La primera se realiza fuera de lı́nea entre dos sesiones. Por el contrario, la redistribución
dinámica se produce en tiempo de ejecución.
Retomando los sistemas de ejemplo, podemos decir que el sitio Web de Sedan-Bouillon soporta todos los tipos de redistribución, i.e., distribución parcial o completa de sus espacios de
trabajo (tı́tulo del sitio Web, contenido y menú) entre diferentes dispositivos (cf. Figura 2.3
tomada de [Balme et al., 2005]). Cuando el sitio Web se ejecuta por completo en una PC o una
PDA, este permanece centralizado (cf. Figura 2.3.a); el sitio Web puede pasar de un estado
centralizado a uno distribuido cuando se divide entre ambos dispositivos, e.g., el menú en la
PDA y el contenido en la PC (cf. Figura 2.3.b); posteriormente el sitio Web puede volverse
a redistribuir al cambiar los componentes de lugar, e.g., el menú en la PC y el contenido en
la PDA (cf. Figura 2.3.d). Finalmente, el sitio Web también se puede concentrar en un solo
dispositivo, e.g., en la PC (cf. Figura 2.3.c).
Roomware soporta tres tipos de redistribución (cf.
Figura 2.4 tomada de
[Prante et al., 2004]). La IU de este sistema se encuentra centralizada en InteracTable y en
CommChair (cf. Figura 2.4.a), pero puede pasar a un estado distribuido cuando la IU es
desplegada en los tres pizarrones electrónicos que conforman DynaWall (cf. Figura 2.4.b).
Asimismo, Roomware puede pasar de un estado distribuido a uno centralizado cuando concentra su IU, que fue previamente desplegada en DynaWall, en InteracTable o CommChair (cf.
Figura 2.4.c).
CamNote soporta la redistribución de centralizada a distribuida y viceversa. Como se mencionó anteriormente, dicho sistema está compuesto de dos espacios de trabajo: uno contiene el
visor de diapositivas, mientras que el otro comprende un panel de control para navegar entre
las diapositivas y un editor de notas (cf. Figura 2.5 tomada de [Demeure et al., 2005]). Ambos espacios de trabajo despliegan como fondo un visor que muestra video en tiempo real del
20
a) Centralizada (PC o PDA)
b) Distribuida (PC y PDA)
Título
Menú
Contenido
c) Centralizada (PC)
Contenido
Menú
d) Distribuida (PC y PDA)
Título
Título
Menú
Contenido
Menú
Contenido
Figura 2.3: Todos los niveles de redistribución en el sitio Web de Sedan-Bouillon
usuario (cf. Figura 2.5.a). Cuando CamNote detecta una pocket PC, el espacio de trabajo que
contiene el panel de control migra de la PC a la pocket PC, mientras que el espacio que contiene
Capı́tulo 2
21
b) Distribuida
a) Centralizada
CommChair
InteracTable
DynaWall: tres pizarrones electrónicos
c) Centralizada
InteracTable
Figura 2.4: Niveles de redistribución de Roomware: de centralizada a centralizada (desde “c”
hacia “a”), de centralizada a distribuida (desde “a” hacia “b”) y de distribuida a centralizada
(desde “b” hacia “c”)
las diapositivas se mantiene en la PC (cf. Figura 2.5.b). CamNote regresa al estado inicial de
redistribución de la IU (i.e., organización centralizada) cuando la PC detecta la ausencia de la
pocket PC (cf. Figura 2.5.a).
Tanto ConnecTables [Tandler et al., 2001] como MindMap [Lucero et al., 2010] poseen la caracterı́stica de ejecutarse sobre dispositivos del mismo tipo. El primero se ejecuta sobre tablets y
el segundo funciona sobre teléfonos celulares. Aún con la peculiaridad anterior, ambos soportan
dos tipos de distribución: a) de centralizada a distribuida y b) de distribuida a centralizada.
Dichas distribuciones son implementadas al momento de acoplar o desacoplar los dispositivos
manipulados por cada sistema. Durante el acoplamiento se crea una sola área de trabajo entre
los dispositivos participantes, pero al separarlos el área de trabajo se concentra en cada dispositivo (cf. Figuras 2.6 y 2.7 tomadas de [Tandler et al., 2001] y de un video2 , respectivamente).
2
Lucero, A., Keranen, J., and Hannu, K., MindMap: Collaborative Use of Mobile Phones for Brainstorming
(MobileHCI ’10), Extraı́das del video URL: http://www.youtube.com/watch?v=-I6kEii03wo, 2010
22
b) Distribuida (PC y pocket PC)
a) Centralizada (PC)
Panel de
control
Editor de
notas
Visor de
diapositivas
Visor de
diapositivas
Panel de
control
Figura 2.5: Niveles de redistribución de CamNote: de centralizada (en una PC) a distribuida
(entre una PC y una pocket PC) y viceversa
a) Centralizada
ConnecTable
b) Distribuida
Acoplamiento de dos ConnecTables
Figura 2.6: Niveles de redistribución de ConnecTables: de centralizada a distribuida y viceversa
Finalmente, FlexClock, el sistema de control de calefacción y Ubidraw solo se ejecutan en
una PC.
2.2.3
Migración
La migración de la IU de un sistema se refiere a la transferencia total o parcial de sus componentes a los diferentes dispositivos de interacción activos, sin importar si estos dispositivos
pertenecen o no a la plataforma actual. La migración es total si la IU se mueve por completo a
una plataforma diferente. Por otra parte, la migración es parcial cuando sólo un subconjunto
Capı́tulo 2
a) Centralizada
23
b) Distribuida
Un teléfono celular
Acoplamiento de tres teléfonos celulares
Figura 2.7: Niveles de redistribución de MindMap: de centralizada a distribuida y viceversa
de la IU (a nivel de espacio de trabajo, interactor o pı́xel) se mueve a diferentes dispositivos de
interacción, e.g., cuando se incorpora una PDA, los paneles de control de un editor de gráficos
migran a la PDA (migración a nivel de espacio de trabajo).
La migración es de dos tipos [Coutaz and Calvary, 2008]:
1. Estática: cuando se realiza fuera de lı́nea entre dos sesiones;
2. Dinámica: cuando se produce en tiempo de ejecución.
Las técnicas de migración y redistribución son diferentes, e.g., una IU centralizada puede ser
redistribuida, pero no migrable (redistribución estática) o una IU centralizada puede migrar,
pero si la migración es total seguirá estando centralizada en un dispositivo.
2.3
Granularidad de adaptación
La granularidad de los componentes de la IU de un sistema denota la unidad más pequeña
de software que puede ser afectada por la remodelación y/o redistribución, las cuales pueden
ser totales o parciales [Vanderdonckt, et al., 2008]. Cuando es parcial, la remodelación y/o
la redistribución se pueden llevar a cabo a nivel de espacio de trabajo, interactor y pı́xel. A
continuación, se describen los diferentes niveles de la granularidad [Coutaz and Calvary, 2008]:
• Total: implica modificar completamente la IU;
• Espacio de trabajo: se refiere a distribuir la IU a nivel de espacio de trabajo, el cual
se define como un espacio que apoya la ejecución de un conjunto de tareas lógicamente
24
conectadas. Los proyectos Pick and Drop y PebblesDraw ofrecen ejemplos de distribución
de la IU a nivel de espacio de trabajo, el cual está concretizado por la paleta de colores,
el teclado y las imágenes de Pick and Drop y por las notas, los tı́tulos y los horarios de
PebblesDraw (cf. Figuras 2.8 a y b tomadas de [Rekimoto, 1997, Myers, 2001], respectivamente);
• Interactor: es un caso especial del espacio de trabajo, donde la unidad de distribución es
un interactor elemental, e.g., en las superficies aumentadas de Rekimoto (cf. Figura 2.8.c
tomada de [Rekimoto and Saitoh, 1999]) los conceptos del dominio, e.g., las mesas y sillas
de una herramienta de diseño de interiores pueden ser desplegadas entre computadoras
personales, superficies horizontales (e.g., mesas) y verticales (e.g., pantallas);
• Pı́xel: se refiere a cualquier componente de la IU que puede ser dividido en múltiples superficies, e.g., en las superficies aumentadas de Rekimoto, una ventana se despliega sobre
dos mesas juntas, como si estas fueran controladas por una sola computadora (cf. Figura
2.8.c). Es importante hacer notar que esta granularidad solo concierne a la redistribución
de la IU.
a) Pick and drop
b) PebblesDraw
c) Superficies aumentadas
Figura 2.8: Grano de adaptación en otros sistemas interactivos
Capı́tulo 2
25
Retomando los sistemas de ejemplo, se puede categorizar el sistema FlexClock a nivel de
interactor, en cuanto a la granularidad de la adaptación, debido a que sus componentes (hora
y fecha) son tareas independientes, pero su presentación (tamaño, forma y alineación) depende
del tamaño de la ventana (cf. Figura 2.9 tomada de [Grolaux et al,. 2002]).
Tarea: hora
Tarea: fecha
Figura 2.9: Grano de adaptación a nivel de tarea en FlexClock
El sistema de control de calefacción transforma su IU en dos granularidades: total e interactor
(cf. Figura 2.10 tomada de [Coutaz and Calvary, 2008]). En el primer caso, aunque la IU gráfica
no cambia de manera significativa cuando el sistema es accedido desde una PC o una PDA,
la IU se convierte en textual cuando el sistema se ejecuta en un teléfono móvil o un reloj (cf.
Figura 2.10.a). En el caso de la adaptación a nivel de interactor, la IU desplegada en una PC
presenta una sola vista, mientras que en una PDA la IU es estructurada en tres vistas (una por
cuarto) a través de las cuales el usuario puede navegar usando pestañas (cf. Figura 2.10.b).
El sitio Web de Sedan-Bouillon remodela su IU a nivel de espacio de trabajo porque la
presentación (tamaño, posición y alineación) de los componentes de la página (tı́tulo, contenido y menú) es modificada cuando esta es cargada en una PDA (cf. Figura 2.11 tomada de
[Balme et al., 2005]).
El sistema Ubidraw también transforma su IU a nivel de espacio de trabajo, el cual está
representado por cada una de sus cinco barras de herramientas (i.e., File, Drawing, Option,
Retouch e Information) las cuales organizan sus ı́conos de acuerdo a la tarea que está realizando
el usuario. Ubidraw se adapta al nuevo contexto de uso al cambiar el tamaño (e.g., ocultando o
26
a) Grano de adaptación: Total
Interfaz gráfica
Interfaz textual
b) Grano de adaptación: Interactor
Despliegue en una sola vista
Despliegue en tres vistas
Figura 2.10: Granos de adaptación a nivel total y de interactor en el sistema de control de
calefacción
mostrando algunos iconos) y la alineación (e.g., vertical u horizontal) de las barras dependiendo
de la actual tarea, la frecuencia de la tarea y la preferencia del usuario por alguna tarea (cf.
Figura 2.12 tomada de [Vanderdonckt and González-Calleros, 2008]).
Ası́ como Sedan-Bouillon y Ubidraw, CamNote adapta su IU a nivel de espacio de trabajo,
particularmente cuando el panel de control migra desde una PC hacia una PDA. Dicha transfor-
Capı́tulo 2
27
Diferente forma de
presentar el contenido
Menú diferente en
tamaño y posición
Figura 2.11: Grano de adaptación a nivel de espacio de trabajo en el sitio Web de SedanBouillon
La barra Options ocultó sus iconos
La barra Retoucher cambió de posición y de alineación
Figura 2.12: Grano de adaptación a nivel de espacio de trabajo en el sistema Ubidraw
mación causa la desaparición tanto del editor de notas como del visor de video para adaptarse
al reducido espacio del dispositivo destino (cf. Figura 2.13 tomada de [Demeure et al., 2005]).
Roomware usa un grano de adaptación a nivel de pı́xel cuando la IU es distribuida en los
tres pizarrones electrónicos de DynaWall (cf. Figura 2.14 tomada de [Prante et al., 2004]).
28
a) Panel de control sobre una PC
b) Panel de control sobre una Pocket PC
Video
Panel de control
Mismo espacio de trabajo, menos
componentes y diferentes dispositivos
Editor de texto
Figura 2.13: Grano de adaptación a nivel de espacio de trabajo en el sistema CamNote
ConnecTables también se adapta a nivel de pı́xel, porque permite a los usuarios tanto duplicar
como tomar y soltar una imagen desde una tablet PC hacia otra cuando trabajan de manera
colaborativa (cf. Figura 2.15 tomada de [Tandler et al., 2001]). Otro sistema que se adapta a
nivel de pı́xel es MindMap, el cual soporta la división de un mapa mental entre varios teléfonos
celulares (cf. Figura 2.16 tomada de [Lucero et al., 2010]).
Imagen dividida
DynaWall: tres pizarrones electrónicos
Figura 2.14: Grano de adaptación a nivel de pı́xel en el sistema Roomware
Capı́tulo 2
29
La imagen está siendo arrastrada
desde un dispositivo a otro
Figura 2.15: Grano de adaptación a nivel de pı́xel en el sistema ConnecTables
El mapa mental está dividido entre dos
teléfonos celulares
Figura 2.16: Grano de adaptación a nivel de pı́xel en el sistema MindMap
2.4
Granularidad de recuperación del estado
La granularidad del estado de recuperación [Vanderdonckt, et al., 2008] caracteriza el esfuerzo
de los usuarios que deben realizar para continuar su actividad después de ocurrida la adaptación.
Existen diversos niveles de recuperación, los cuales se mencionan a continuación:
• Nivel de sesión: el usuario tiene que reiniciar su actividad desde el estado inicial del
sistema, i.e., el estado en el que el sistema inicia cuando es lanzado;
• Nivel de tarea: el usuario puede continuar el trabajo desde el inicio de la tarea interrumpida (a condición de que la tarea es realizable en la IU);
• Nivel de acción fı́sica: el usuario puede continuar la tarea actual en el punto exacto
donde la interrumpió (a condición de que la tarea es realizable en la nueva versión de la
IU).
30
El sitio Web de Sedan-Bouillon soporta una recuperación de estado a nivel de tarea porque
solo se pierde la tarea actual del usuario, e.g., si ocurre la redistribución de la IU mientras el
usuario está llenando una forma, él tendrá que comenzar nuevamente a llenarla (cf. Figura 2.17
tomada de [Balme et al., 2005]), pero los resultados de las tareas previas no se verán afectados.
Por otro lado, CamNote [Coutaz and Calvary, 2008] soporta la recuperación a nivel de acción
fı́sica, ya que conserva la diapositiva actual cuando el panel de control migra desde la PC a
la PDA. El sistema MindMap [Lucero et al., 2010] soporta una recuperación a nivel de acción
fı́sica porque al unir o separar los teléfonos celulares, el mapa mental se conserva sin cambios,
e.g., suponga que en un arreglo de tres teléfonos celulares se muestra un mapa en escala 1:1
(cf. Figura 2.18.a tomada de un video3 ); si uno de los colaboradores toma alguno de estos
dispositivos, el mapa mental será escalado hasta desplegarse por completo en la pantalla de
dicho teléfono; además, el mapa continúa mostrándose sin alteración alguna en los otros dos
dispositivos (cf. Figura 2.18.b tomada de un video3 ). El resto de los sistemas no proveen
suficiente información para inferir el estado de recuperación que implementan.
a) Antes de la adaptación (PC)
b) Después de la adaptación (PC y PDA)
restaurants
anglais
x
Perdida de información
Figura 2.17: Grano de recuperación a nivel de tarea en el sitio Web de Sedan-Bouillon
2.5
Despliegue de la interfaz de usuario
El despliegue de la IU puede ser estático o dinámico. Un despliegue estático significa que
la adaptación de la IU se realiza cuando el sistema es lanzado en ejecución. En este tipo de
despliegue no puede efectuarse remodelación ni redistribución de la IU, e.g., el sistema Pick and
Drop [Rekimoto, 1997] realiza un despliegue estático porque muestra una versión prediseñada
y precalculada del sistema para una plataforma particular. Por el contrario, un despliegue
3
Lucero, A., Keranen, J., and Hannu, K., MindMap: Collaborative Use of Mobile Phones for Brainstorming
(MobileHCI ’10), Extraı́das del video URL: http://www.youtube.com/watch?v=-I6kEii03wo, 2010
Capı́tulo 2
31
a) Antes de la adaptación
b) Después de la adaptación
El mapa conceptual se conserva ántes
y despuésde la adaptación
Figura 2.18: Grano de recuperación a nivel de acción fı́sica en el sistema MindMap
dinámico significa que la remodelación y la redistribución se pueden realizar en tiempo de
ejecución [Vanderdonckt, et al., 2008].
Observe que un despliegue dinámico que soporta recuperación a nivel de sesión es diferente
de un despliegue estático. En el primer caso, la remodelación y/o la redistribución ocurren
durante la ejecución del sistema, provocando que el usuario regrese al estado de inicio. En
el caso del despliegue estático se fuerza al usuario a salir de la sesión y a lanzar la versión
apropiada del sistema.
Analizando el despliegue de la IU en los sistema de ejemplo, podemos decir que el sitio Web
de Sedan-Bouillon provee un despliegue dinámico cuando redistribuye su espacio de trabajo. De
la misma manera, FlexClock remodela dinámicamente la ventana de interactores (e.g., alarga
el reloj analógico y centra el reloj digital) cuando el usuario redimensiona la ventana. Ubidraw
también adapta su espacio de trabajo dinámicamente cuando el usuario lo redimensiona, e.g., si
el espacio disponible es relativamente pequeño, solo los iconos relacionados con la tarea actual
son accesibles.
Por otro lado, ConnecTables crea dinámicamente el espacio de trabajo compartido (vs. personal) cuando dos usuarios acoplan (vs. desacoplar) sus tablets. De la misma manera que
ConnecTables, MindMap ofrece un despliegue dinámico al permitir a los colaboradores desplegar a su gusto los mapas metales sobre varios teléfonos celulares. Sin embargo, el sistema de
control de calefacción, CamNote y Roomware proveen despliegue estático.
32
2.6
Cobertura del contexto de uso
El contexto de uso hace referencia a los espacios de información que sirven al proceso
de adaptación cuando el contexto cambia. Un cambio en el contexto se define como
la modificación del valor de cualquier elemento del espacio de información contextual
[Coutaz and Calvary, 2008]. Por contexto de uso se entiende la terna ≪usuario, plataforma,
entorno≫ [Calvary et al., 2004, Calvary et al., 2001] donde:
• El usuario denota el arquetipo humano que tiene por objeto utilizar el sistema interactivo.
• La plataforma se refiere a los dispositivos de hardware y software disponibles para llevar
a cabo la interacción del usuario con el sistema. La plataforma puede ser modelada en
términos de los recursos computacionales que determinan la forma en que se procesa, se
transmite y se presenta la información, ası́ como la manera en que el usuario manipula la
información. Comúnmente el tamaño de la memoria, el ancho de banda de la red y los
dispositivos de interacción motivan la selección de un conjunto de modalidades de E/S y la
cantidad de información disponible. Un cluster de dispositivos computacionales conectados puede ser considerado como parte de la plataforma. Alternativamente, el cluster puede
ser estático o dinámico, i.e., los dispositivos computacionales pueden aparecer y desaparecer automáticamente; la cardinalidad del cluster es un factor importante a considerar en
lo referente a la escalabilidad y la usabilidad. Los dispositivos computacionales también
están caracterizados por los dispositivos de E/S que soportan [Vanderdonckt, et al., 2008],
e.g., ratón, teclado, pantalla táctil, stylus y voz.
• El entorno describe las condiciones fı́sicas y sociales donde tiene lugar la interacción,
e.g., los objetos, las personas y los eventos que son periféricos a la tarea que se está desarrollando, en un momento dado, pero que pueden tener un impacto en el comportamiento:
a) del sistema, e.g., un entorno ruidoso puede eliminar la realimentación por audio, y/o b)
del usuario, e.g., su localización provee un contexto para la relevancia de la información.
Analizando los sistemas interactivos mono-usuarios se puede observar que el sitio Web de
Sedan-Bouillon pueden ser accedido desde una PC y una PDA (adaptación a la plataforma).
Además, este sitio identifica al usuario cuando está trabajando desde diferentes dispositivos
(adaptación al usuario, cf. Figuras 2.19 a y b tomadas de [Balme et al., 2005]).
Ubidraw no solo se adapta a una PC y una pocket PC (adaptación a la plataforma),
sino también adapta su IU al tamaño de la ventana de acuerdo a la tarea actual (e.g.,
el último icono que fue seleccionado), la frecuencia de la tarea (e.g., la cantidad de clics
sobre cada ı́cono) y la preferencia del usuario por una tarea (e.g., la posición del ı́cono
en las preferencias/necesidades de dicho usuario). La adaptación a la tarea propuesta por
Ubidraw es parte del elemento “usuario” del contexto de uso (cf. Figura 2.20 tomada de
[Vanderdonckt and González-Calleros, 2008]).
Capı́tulo 2
33
a) Plataforma
b) Usuario
Dispositivo: PC
Dispositivo: PDA
Mismo usuario, Lionel,
en dos dispositivos (0 y 1)
Figura 2.19: Adaptación a la plataforma y al usuario en el sitio Web de Sedan-Bouillon
a) Pocket PC
b) PC
Adaptación al usuario
Figura 2.20: Adaptación a la plataforma y al usuario en el sistema Ubidraw
El sistema de control de calefacción se adapta al hardware y al software (adaptación a la
plataforma) porque se ejecuta en aplicaciones Web o independientes; este sistema también
permite consultar la temperatura de los cuartos desde dispositivos diferentes, e.g., PDA, PC,
teléfono móvil y reloj (cf. Figura 2.21 tomada de [Vanderdonckt and González-Calleros, 2008]).
En cambio, FlexClock solo puede ser ejecutado sobre una PC, pero adapta su IU al tamaño de
la ventana (simula la adaptación a la plataforma).
CamNote se adapta a la plataforma debido a que puede ejecutar el panel de control sobre una
PDA. Cuando este componente es transferido a dicho dispositivo, se pierde el video en tiempo
real del usuario, ası́ como el editor de notas (cf. Figura 2.22 tomada de [Demeure et al., 2005]).
34
a) PC
b) PDA
c) Teléfono móvil
d) Reloj digital
Figura 2.21: Adaptación a la plataforma en el sistema de control de calefacción
a) PC
b) Pocket PC
Figura 2.22: Adaptación a la plataforma en el sistema CamNote
Por otro lado, Roomware está habilitado para ejecutarse en tres diferentes dispositivos: DynaWall, InteracTable y CommChair (cf. Figura 2.23 tomada de [Prante et al., 2004]). Dos
ejemplos de plataforma diferentes a los anteriores son ConnecTables y MindMap. Para crear
Capı́tulo 2
35
un espacio compartido, el primer sistema permite acoplar dos tablets (cf. Figura 2.24 tomada
de [Tandler et al., 2001]) y el segundo facilita la formación de un arreglo de dos o más teléfonos
celulares (cf. Figura 2.25 tomada de [Lucero et al., 2010]). Del lado derecho de la figura 2.25
se muestran las posibles opciones para acoplar teléfonos celulares en MindMap.
a) Plataforma
b) Usuario
Dispositivo: PC
Dispositivo: PDA
Mismo usuario, Lionel,
en dos dispositivos (0 y 1)
Figura 2.23: Adaptación a la plataforma en el sistema Roomware
Detección física para crear un espacio compartido
Figura 2.24: Adaptación a la plataforma en el sistema ConnecTables
En los sistemas analizados podemos observar que ninguno se adapta al entorno.
36
Dos o mas teléfonos celulares forman un
espacio
Figura 2.25: Adaptación a la plataforma en el sistema MindMap
2.7
Cobertura de espacio tecnológico
Un espacio tecnológico es un contexto de trabajo que incorpora un conjunto de conceptos
asociados, bases de conocimientos, herramientas, habilidades requeridas y posibilidades.
Algunos espacios incluyen herramientas de documentos expresados en XML (documentware),
herramientas de datos relacionadas con los sistemas de base de datos y herramientas de
ontologı́as (dataware). La mayorı́a de las interfaces de usuario se ejecuta dentro de un solo
espacio tecnológico, e.g., Tcl/Tk, swing, o HTML. Esta homogeneidad no es conveniente
en las interfaces de usuario plásticas multi-modales, puesto que la redistribución a diversos
dispositivos computacionales puede requerir atravesar varios espacios tecnológicos, e.g., una IU
en Java se debe transformar en una IU en WML 2.0 (Wireless Markup Language) al emigrar de
una PDA a un teléfono móvil WAP (Wireless Application Protocol) [Vanderdonckt, et al., 2008].
La cobertura del espacio tecnológico denota la capacidad de permitir la plasticidad de la IU
en los espacios tecnológicos, los cuales se dividen de la siguiente manera:
• intra-Espacio tecnológico: corresponde a la IU que se ejecuta y se adapta a un solo
espacio tecnológico;
• inter-Espacio tecnológico: se refiere a la IU que es transformada en un espacio tecnológico diferente al actual;
• multi-Espacio tecnológico: concierne a las interfaces de usuario fuente y/o destino
compuestas de componentes expresados en espacios tecnológicos distintos.
Analizando el espacio tecnológico en los sistemas interactivos de ejemplo, podemos observar que el sitio Web Sedan-Bouillon —HTML/PHP [Balme et al., 2005]—,
Capı́tulo 2
37
Ubidraw —Mozart/QTk/Oz [Vanderdonckt and González-Calleros, 2008]—, FlexClock —Qtk
[Grolaux et al,. 2002]— y MindMap —C++/Qt [Lucero et al., 2010]— permanecen dentro del
mismo espacio tecnológico antes y después de la adaptación plástica (i.e., intra-TS). El resto
de los sistemas no ofrecen alguna información relacionada.
2.8
Meta-interfaz de usuario
El concepto de Meta-Interfaz de Usuario (Meta-IU) se define como la simplificación de un
entorno de desarrollo de usuario final. Una meta-IU completa debe permitir a los usuarios
finales programar (configurar y controlar) sus espacios interactivos, eliminar errores (evaluar),
además de mantener y reutilizar programas. Dicha meta-IU determina las actividades que
pueden ejecutarse en un espacio interactivo. La meta-IU considera diversos niveles, los cuales
se presentan a continuación [Vanderdonckt, et al., 2008]:
• plasticidad en la propia meta-IU: es un tema en exploración, puesto que cada meta-IU
se encuentra en un entorno cambiante;
• sin negociación: permite que el usuario observe el proceso de adaptación, pero no le
permite que intervenga; en este caso el sistema es autónomo;
• con negociación: es recomendable cuando la meta-IU no puede tomar decisiones entre
las múltiples formas de adaptación, o cuando el usuario debe controlar por completo el
resultado del proceso. En este tipo de meta-IU, se presenta el problema de equilibrar la
autonomı́a del sistema y la negociación con el usuario;
• inexistente: se refiere la carencia de un entorno de desarrollo de usuario final.
La dimensión recurrente de la meta-IU requiere definir una meta-IU autosuficiente, capaz de
instanciar la apropiada meta-IU cuando el sistema es lanzado en ejecución.
Examinando los sistemas de prueba, el sitio Web Sedan-Bouillon [Balme et al., 2005] es el
único que provee una meta-IU con negociación, porque el usuario coopera con el sistema para
la redistribución de los espacios de trabajo de la IU, i.e., el tı́tulo de la página principal, el
contenido y el menú (cf. Figura 2.26 tomada de [Balme et al., 2005]). Finamente, CamNote
implementa una meta-IU sin negociación porque no permite que el usuario participe en el
proceso de adaptación, pero este sistema provee conciencia de adaptación cuando el panel de
control migra desde una PC a una PDA.
38
Meta-IU
Figura 2.26: Meta-IU con negociación en el sitio Web de Sedan-Bouillon
2.9
Otras dimensiones
Otras dimensiones importantes corresponden a tipo de adaptación, contexto monoentidad o multi-entidad y variables contextuales.
2.9.1
Tipo de adaptación
El tipo de adaptación comprende las siguientes maneras [Abowd et al., 1999]:
• presentación de información y servicios al usuario: se refiere a una técnica de
interacción en donde se presenta una lista de objetos (e.g., impresoras) o lugares (e.g.,
oficinas) cuyos elementos más relevantes, de acuerdo al contexto de uso, son enfatizados
o más fáciles de escoger.
• ejecución automática de un servicio: en este caso no solo se presenta información
relevante sino que, dada la correcta combinación de condiciones contextuales, se ejecuta
automáticamente una acción.
• información aumentada: algunos datos contextuales pueden ayudar a comprender
mejor el entorno colaborativo en el que se trabaja, e.g., se puede identificar bajo qué
situaciones las personas son más activas.
El sistema de control de calefacción, Ubidraw, FlexClock y Sedan-Bouillon se enfocan en la
presentación de información y servicios. Dependiendo del tamaño de la pantalla disponible, el
sistema de control de calefacción puede mostrar simultáneamente todos los cuartos o enfatizar
el preferido por el usuario. Las herramientas de Ubidraw son reordenadas y resaltadas dependiendo su frecuencia de uso. Por otro lado, FlexClock presenta la hora y/o la fecha, dependiendo
del espacio disponible de la ventana. Cuando detecta dos dispositivos cercanos que acceden al
Capı́tulo 2
39
sitio Web de Sedan-Bouillon, este sistema provee al usuario de una meta-IU para seleccionar
los componentes de la IU que pueden ser desplegados en cada dispositivo.
Varios de los sistemas de ejemplo se enfocan en ejecutar automáticamente un servicio, como
es el caso de CamNote, Roomware, MindMap y ConnecTables. CamNote permite la ejecución
automática de un servicio, ya que transfiere instantáneamente el panel de control hacia una
pocket PC cuando detecta este dispositivo. Roomware está centrado en la ejecución automática
de servicios, pues es capaz de desplegar los espacios de trabajo privados y compartidos en
dispositivos personales y públicos, respectivamente.
ConnecTables también está en la categorı́a de ejecución automática de un servicio porque
este convierte dos espacios de trabajo privados en uno compartido cuando dos tablets se acoplan
y viceversa. Al unir las tablets, el espacio de trabajo provee a los colaboradores con funciones
que permiten copiar y mover objetos desde una tablet hacia otra.
MindMap realiza la ejecución automática de dos servicios, los cuales corresponden a: 1)
crear un espacio común entre los teléfonos y 2) escalar el mapa mental. El primer servicio se
ejecuta cuando los colaboradores unen dos o más teléfonos celulares por medio de gesticulaciones
manuales. El segundo servicio se refiere a dos tipos de escalamiento automático de los mapas
mentales. El primero concierne al escalamiento 1:1, el cual se realiza cuando dos o más teléfonos
forman un arreglo. El otro tipo de escalamiento requiere que el mapa mental sea ajustado a la
pantalla de un dispositivo cuando este deja de formar parte del arreglo.
2.9.2
Sistemas mono-entidad o multi-entidad
Los sistemas mono-entidad consideran la situación de una sola entidad que participa a lo largo
de la ejecución del sistema, e.g., un usuario en particular puede cambiar varias veces el tamaño
de su ventana o expresar sus preferencias en un sistema, el cual es mono-entidad porque en
todo momento atiende a un solo usuario. Mientras que los sistemas multi-entidad consideran
la situación de varias entidades de forma simultánea, e.g., los miembros de una organización
[Olivares, 2011].
En la tabla 2.1 se muestra el análisis de los sistemas de ejemplo respecto al carácter mono y
multi -entidad. Dada la naturaleza cooperativa de ConnecTables, Roomware y MindMap, estos
sistemas son multi-entidades porque ellos consideran la presencia de múltiples colaboradores y
el estado de sus respectivos dispositivos (e.g., si ellos están acoplados/desacoplados o si son de
ámbito personal o público).
Aún cuando Sedan-Bouillon solo soporta un usuario, este sitio Web corresponde a la categorı́a
multi-entidad porque su ejecución puede ser compartida entre dos dispositivos cercanos cuando
es requerido. Por el contrario, Ubidraw es un sistema mono-entidad porque solo considera el
estado de un solo usuario, el cual es expresado por la tarea actual y las preferencias, la frecuencia
de uso de la herramienta y el tamaño de la ventana. El sistema de control de calefacción también
es mono-entidad porque solo considera el estado de una plataforma de ejecución a la vez, en
40
particular el tamaño de la pantalla. Otro sistema mono-entidad es FlexClock, ya que solo
toma en cuenta el tamaño de la ventana disponible. Aún cuando el sistema CamNote es monousuario, este sistema es multi-entidad, puesto que puede reconocer la presencia de una PDA a
cierta distancia de una PC.
Sistema
Soporte
multi-entidad
Entidades
Sedan-Bouillon
Sı́
Usuario y dispositivos
Control de calefacción
No
Dispositivo
FlexClock
No
Tamaño de la ventana
Ubidraw
No
Usuario
CamNote
Sı́
Dispositivos
ConnecTables
Sı́
Colaboradores y dispositivos
Roomware
Sı́
MindMap
Sı́
Tabla 2.1: Entidades contempladas por los sistemas analizados
2.9.3
Variables contextuales
Las variables contextuales se refieren a las variables relevantes que los sistemas consideran
para llevar a cabo la adaptación [Ghiani et al., 2009].
La tabla 2.2 muestra las variables contextuales consideradas para la adaptación de los propios
sistemas. La mayorı́a de los sistemas analizados usan variables fı́sicas, e.g., localización, tamaño
de la pantalla, proximidad, tipo de dispositivo, hora y fecha. Como la mayorı́a de los sistemas
cooperativos, ConnecTables y Roomware soportan variables tı́picamente lógicas, tales como la
presencia de los colaboradores en el espacio de trabajo compartido. En cambio, el sistema
UbiDraw toma en cuenta variables lógicas más sofisticadas, e.g., preferencias del usuario y la
frecuencia de uso de las herramientas.
En el caso de ConnecTables, los sensores detectan cuando dos de estos dispositivos están
Capı́tulo 2
41
acoplados. En cambio en MindMap, la adaptación se lleva a acabo cuando se detecta los gestos
con las manos de los colaboradores para indicar la unión de dispositivos, ası́ como cuando un
colaborador toma en su mano el dispositivo; dicha acción es registrada por el acelerómetro
incluido en el teléfono.
Sistema
Sedan-Bouillon
Preferencia de los usuarios y sensores de proximidad de los dispositivos
Control de calefacción
Tamaño de la pantalla del dispositivo
FlexClock
Tamaño de la ventana
Ubidraw
Tarea actual, tamaño de la ventana y frecuencia
de uso de las herramientas
CamNote
Sensores de proximidad de los dispositivos
ConnecTables
Presencia de los colaboradores y sensores de proximidad de los dispositivos
Roomware
Presencia de los colaboradores y carácter público
o personal de los dispositivos
MindMap
Gesticulaciones manuales y si un dispositivo forma
parte o no de un arreglo
Tabla 2.2: Variables contextuales de los sistemas analizados
2.10
Conclusiones
Este capı́tulo muestra una subárea del campo de Interacción Humano-Computadora (IHM) llamada “Plasticidad de las Interfaces de Usuario”; dicha subárea es importante para el desarrollo
del presente trabajo de investigación porque propone considerar varios puntos relevantes para
crear una interfaz de usuario plástica en la etapa de diseño o en tiempo de ejecución. También,
sistemas plásticos deben informar al usuario final acerca de la nueva adaptación, ya sea que el
usuario intervenga en el proceso de adaptación o solo sea un observador pasivo.
Varios de los sistemas de ejemplo permiten expresar de manera visual la plasticidad, e.g.,
42
cambiar de modalidad gráfica a textual cuando el dispositivo no lo soporte; redistribuir la IU
entre dispositivos heterogéneos (e.g., pizarrones electrónicos, PDA, PC y mesas) y adaptarse a
la tarea del colaborador.
En los ejemplos presentados, se observa que la mayorı́a de los sistemas se adaptan a la
plataforma, principalmente estos sistemas se ejecutan sobre PDAs, tablets PC y computadoras
portátiles; otras plataformas menos usadas son pizarrones electrónicos, teléfonos inteligentes o
relojes. Muy pocos de estos sistemas consideran al usuario. La tendencia respecto al usuario
es considerar las tareas (frecuencia y preferencia) o reconocer cuando un mismo usuario está
usando dos o más dispositivos.
Capı́tulo 3
Marcos de desarrollo de sistemas
plásticos
En este capı́tulo se presentan siete marcos (frameworks) que fueron seleccionados por ser los más
representativos del tema de investigación. Por cada marco se proporciona una breve descripción
con la finalidad de resaltar sus caracterı́sticas más importantes. Los dos primeros, RUIUM-O y
CAMELEON-RT, facilitan el desarrollo de sistemas mono-usuario, mientras que los restantes
están enfocados en el desarrollo de sistemas colaborativos. A nuestro saber, el marco RUIUM-O
es el primero en considerar el contexto de uso y algunas otras dimensiones de la plasticidad,
e.g., percutores y Meta-IU en la creación de interfaces de usuario (cf. Sección 3.1). El marco
CAMELEON-RT también considera el contexto de uso, ası́ como la redistribución y la migración
de la interfaz de usuario (cf. Sección 3.2).
El marco de PI es el primero en hacer converger aspectos de las interfaces de usuario plásticas
de los sistemas mono-usuario y aspectos del trabajo colaborativo, e.g., conciencia de grupo
(cf. Sección 3.3). El marco PEC contempla el contexto de uso, la conciencia de grupo e
implı́citamente la Meta-IU (cf. Sección 3.4). Mientras que los marcos ACCDP (cf. Sección 3.5),
RCCG (cf. Sección 3.6) y GC (cf. Sección 3.7) se enfocan sólo en el contexto de uso, dejando
de lado las demás dimensiones de la plasticidad, e.g., granularidad del estado de recuperación.
En la sección 3.8 del presente capı́tulo se incluye un análisis comparativo de los marcos
analizados, con el fin de destacar sus ventajas y carencias. Finalmente, la sección 3.9 presenta
las conclusiones del presente capı́tulo, las cuales exhiben las posibles tendencias de dichos
marcos.
43
44
Marcos de desarrollo de sistemas plásticos
3.1
Marco de Referencia Unificado para Interfaces de
Usuario Multi-Objetivo
El marco de Referencia Unificado para Interfaces de Usuario Multi-Objetivo (RUIUM-O) pretende servir como referencia para ayudar a diseñadores y desarrolladores a estructurar y desarrollar interfaces de usuario multi-objetivo en la etapa de diseño y en tiempo de ejecución.
Antes de empezar a describir dicho marco es importante mencionar que una interfaz de usuario
multi-objetivo es capaz de soportar múltiples contextos de uso sin considerar la usabilidad
[Calvary et al., 2003, Calvary et al., 2001].
3.1.1
Modelos ontológicos, arquetı́picos y observadores
El modelo general de RUIUM-O se compone de tres grandes partes: la primera corresponde a
los modelos ontológicos, la segunda a los modelos arquetı́picos y la tercera a los modelos
observadores (cf. Figura 3.1).
Modelos Arquetípicos
Modelo Ontológico
Configuración
1
Dominio
Conceptos
(I1)
Conceptos (O1)
Tareas (O2)
Contexto de Uso
Usuario (O3)
Entorno (O5)
Entorno
(I5)
Transición (O7)
(T1)
(I1)
(I2)
Interfaz
Abstracta
(T2)
Usuario
(I3)
Plataforma
(I4)
Evolución (O6)
Configuración
2
Tareas
(I2)
Plataforma (O4)
Adaptación
Modelo de
Conceptos y
Tareas
(T1)
(I3)
(I4)
Interfaz
Concreta
(T3)
Evolución
(I6)
S Interfaz de
C Usuario Final
Configuración
E
Transición
(I7)
Modelos
Observadores
(T2)
(T3)
(T4)
1 (T4)
S
C
E
(I5)
S
C
E
(I6)
(I7)
Infraestructura en tiempo de ejecución
Figura 3.1: Marco de Referencia Unificado para Interfaces de Usuario Multi-Objetivo
Los modelos ontológicos son meta-modelos independientes tanto del dominio como de los
sistemas interactivos. Dichos modelos tienen como objetivo identificar las dimensiones clave
Capı́tulo 3
45
para dar una solución al problema en cuestión. Los modelos ontológicos están representados
por la letra O dentro del marco RUIUM-O (cf. Figura 3.1). Dichos modelos se dividen en:
1. El modelo de dominio contiene tanto la descripción de los conceptos (modelo de
conceptos) como la de las tareas (modelo de tareas) relacionadas a un cierto dominio.
El modelo de conceptos (O1) describe los conceptos que el usuario emplea en cualquier
contexto de uso y puede ser representado mediante diagramas de clases UML. El modelo
de tareas (O2) describe las tareas que el usuario manipula en cualquier contexto de
uso y es representado mediante una estructura ConcurTaskTree 1 , en donde las hojas
corresponden a las tareas de interacción (e.g., leer y seleccionar), los nodos son tareas
abstractas y los vértices representan tanto relaciones temporales como la lógica de las
tareas.
2. El modelo de contexto de uso se refiere a caracterizar el usuario, la plataforma y el
entorno. El modelo de usuario (O3) se basa en hacer aproximaciones acerca del usuario,
mientras que el modelo de plataforma (O4) provee herramientas para describir los recursos cercanos, los cuales están clasificados en dos categorı́as: a) plataforma básica para
referirse tanto a recursos fı́sicos como lógicos que funcionan como una unidad, cuyo estado
puede ser observado o modificado por un usuario humano y b) clusters compuestos de la
plataforma básica que pueden ser homogéneos o heterogéneos. El modelo de entorno
(O5) identifica dimensiones genéricas para describir el entorno cercano.
3. El modelo de adaptación especı́fica tanto la reacción ante un cambio de contexto como
el camino para conmutar entre contextos. El modelo de adaptación funciona a partir
del modelo de evolución y de transición. El modelo de evolución (O6) indica a
los sistemas interactivos cuándo deben adaptarse a cambios, mientra que el modelo de
transición (O7) tiene como objetivo suavizar discontinuidades entre dichos cambios de
contexto.
Los modelos arquetı́picos son modelos predecibles que sirven como entrada en el proceso de
diseño. Dichos modelos combinan una serie de operaciones para generar un sistema interactivo
sensible al contexto, mediante la transformación de modelos iniciales en modelos transitorios.
Los modelos iniciales son descritos por los desarrolladores, mientras que los transitorios son
inferidos por los desarrolladores y/o el sistema a través del proceso de desarrollo. Los modelos
iniciales y transitorios están representados respectivamente por las letras I y T en el marco
RUIUM-O (cf. Figura 3.1). Un modelo transitorio contiene tanto el modelo de tareas y
conceptos (T1), como las interfaces de usuario abstractas (T2) y concretas (T3) necesarias para la producción de la interfaz de usuario final (T4) [Calvary et al., 2003].
La interfaz de usuario abstracta (IU abstracta) es una expresión canónica de los conceptos y funciones, e.g., en la herramienta ARTStudio [Calvary et al., 2001] la interfaz de
usuario es modelada como un conjunto de espacios de trabajos isomorfos al modelo de las
1
Es una notación gráfica que sirve para describir el modelo de tareas [Paterno and Mancini, 1997].
46
Tarea. Los espacios de trabajo, e.g., la temperatura de los cuartos de una casa, son inferidos a partir de las relaciones de las tareas que fueron previamente expresadas en los modelos
de conceptos (I1) y de tareas (I2). Los espacios anteriores, los cuartos de una casa son
representaciones de una tarea abstracta, e.g., actualizar la temperatura.
La interfaz de usuario concreta (IU concreta) convierte una IU abstracta en una expresión dependiente del interactor. Por ejemplo, la herramienta ARTStudio convierte el espacio
de trabajo principal en una ventana, mientras que los demás espacios pueden ser ventanas o
canvas. La IU concreta “se ejecuta dentro del entorno de desarrollo”, e.g., la interfaz de usuario
concreta generada por ARTStudio se ejecuta dentro de la misma herramienta.
Los modelos transitorios son producidos por dos tipos de operaciones: 1) transformación
vertical y 2) transformación horizontal. La transformación vertical se refiere a procesar los
modelos transitorios (tareas y conceptos, IU abstractas y concretas) de abajo hacia arriba o viceversa. Dentro de está transformación se encuentra la reification, la cual cubre el
proceso de derivación desde el modelo de tareas hasta la interfaz de usuario final (T4).
La transformación horizontal corresponde a la translación entre modelos del mismo nivel, en
donde la “translación” significa una operación que transforma la descripción de un objetivo
particular en otra descripción de la misma clase, pero con diferente objetivo. Una operación
cruzada significa tanto trasladarse a otro contexto de uso como cambiar el nivel de reification.
Todas las operaciones de transformación pueden ser ejecutadas de manera automática o manual. La interfaz de usuario final (IU final) es generada a partir de la IU concreta y es
expresada en código fuente, e.g., Java o HTML. Dicha IU final soporta adaptación dinámica
multi-objetivo.
El modelo de evolución (I6) sugiere estructurar la adaptación multi-objetivo en tres etapas: 1) reconocimiento de la situación, 2) procesamiento de la reacción y 3) ejecución de la
reacción. El reconocimiento de la situación registra el contexto (e.g., la temperatura actual
es de 22◦ C), detecta cambios contextuales (e.g., la temperatura ha incrementado de 18◦ C a
22◦ C) y finalmente identifica cambios de contexto (e.g., cambiar la temperatura “regular” por
“confortable”). El procesamiento de la reacción involucra tanto la identificación de las soluciones candidatas como la selección de una solución; esta reacción puede involucrar cambios
de plataforma (e.g., cambiar de una PC a una PDA), cambios de entorno (e.g., encender la
luz porque el cuarto está muy obscuro) o cambiar de código ejecutable debido a que el código
actual no soporta el cambio de contexto. Finalmente, la ejecución de la reacción involucra la
realización de las siguientes acciones:
• prólogo: se encarga de preparar la reacción al completar, suspender o abortar la tarea
actual;
• reacción: implica cambiar hacia la nueva versión (e.g., mostrar una nueva secuencia de
diálogo o ejecutar una tarea especı́fica);
• epı́logo: se encarga de finalizar la reacción al restaurar el contexto de ejecución (e.g.,
restablecer la tarea interrumpida).
Capı́tulo 3
47
Los modelos observadores conducen la adaptación en tiempo de ejecución. Tanto el modelo
ontológicos Oj como su modelo homólogo arquetı́picos Ij pueden ser referenciados por la
infraestructura en tiempo de ejecución o por la IU final (ver Figura 3.1), los cuales están
encargados de la etapa de adaptación (reconocimiento de la adaptación, cálculo y ejecución de
la reacción).
3.1.2
Implementación
Bajo el marco RUIUM-O no se creó ninguna herramienta o caso de estudio, pero los autores
de este marco seleccionaron algunas herramientas dedicadas al diseño de interfaces de usuario
para dar una idea de cómo funciona el marco. Las herramientas seleccionadas son PetShop
[Bastide et al., 2003], SEESCOA [Luyten et al., 2003] y TERESA [Paterno et. al., 2008].
PetShop se basa en redes de Petri con la finalidad de editar, verificar y ejecutar modelos
formales. El caso de estudio que se reporta con dicha herramienta es un simulador de control
de tráfico aéreo que consta de un radar, en el cual se pueden agregar y manipular aviones.
SEESCOA es un conjunto de modelos y mecanismos que genera la IU final en tiempo de
ejecución. Dicha herramienta considera varias plataformas, ası́ como diferentes modalidades.
Finalmente, TERESA ofrece tanto una metodologı́a para diseñar interfaces de usuario multimodales sobre varias plataformas, como una herramienta que sigue dicha metodologı́a. Las
modalidades que soporta esta herramienta son gráfica, vocal, gestos, etc.
Las tres herramientas analizadas agregan tanto un modelo de presentación como un modelo
de diálogo, los cuales no son considerados en el marco analizado. El modelo de presentación
especifica aspectos de la presentación de la IU en términos abstractos, ası́ como la invocación
de ellos, e.g., en un método se especifica cómo presentar gráficamente las propiedades de un
avión. El modelo de diálogo contiene la descripción del comportamiento y la interacción de
las clases.
Existe cierta coincidencia entre los modelos del marco RUIUM-O y las herramientas analizadas, e.g., dichas herramientas cubren completamente los modelos ontológicos, la IU final
(T4) y algunos modelos arquetı́picos (cf. Tabla 3.1).
Los modelos arquetı́picos se componen de modelos Iniciales y transitorios, ası́ como de
la IU final. Como se mencionó en la sección 3.1.1, los modelos Iniciales corresponden a los
siguientes modelos: conceptos (I1), tareas (I2), usuario (I3), plataforma (I4), entorno (I5),
evolución (I6) y transición (I7).
Del conjunto de modelos Iniciales, PetShop solo utiliza el modelo de conceptos (I1) ya que
el desarrollador realiza una descripción de lo que debe hacer el sistema, e.g., cada avión que
forma parte del simulador puede desplegar un menú al dar clic derecho sobre éste. PetShop
no sólo agrega los modelos de presentación y de diálogo, sino también incluye el modelo
de aplicación. Este modelo sirve para dar acceso a los métodos de las clases contenidas en
48
Modelos
Herramienta
ontológicos
PetShop
O1-O7,
ractoresa
arquetı́picos
Inte-
I1, T8 tareasb , T9-T11,
aplicacióna , presentación y
diálogo
Generación
Manual/
Automática
Diseño/
Ejecución
Ambos
Etapa de
diseño
Ambos
Tiempo de
ejecución
Ambos
Etapa de
diseño
Contexto de uso: no aplica
SEESCOA
O1-O7
ractoresa
Inte-
I4, T2-T4, presentacióna ,
diálogo y Dispositivos
Contexto de uso: plataforma
TERESA
O1-O7
ractoresa
Inte-
I1, I2, I4, T1-T4, presentacióna y diálogo
Contexto de uso: plataforma
Tabla 3.1: Herramientas de ejemplo para el marco RUIUM-O
a
b
El marco no considera este componente, pero la herramienta sı́
El marco si lo considera, pero la herramienta no
el modelo de conceptos, e.g., la clase PlaneManager simula un radar para administrar los
aviones y la clase Plane permite crear aviones dentro del radar. El modelo de presentación
que implementa PetShop permite enriquecer la interfaz de usuario mediante tres aspectos: a) la
interpretación de los métodos necesarios para mostrar información en la pantalla, e.g., show()
o hide(), b) la activación relaciona los métodos con los eventos, e.g., despliegue de un menú
mediante un clic derecho sobre un avión y c) una función que se encarga de responder a los
métodos invocados.
De los modelos Iniciales propuestos por el marco RUIUM-O, SEESCOA retoma el modelo
de plataforma (I4), mientras que TERESA se interesa en los modelos de conceptos (I1), de
tareas (I2) y de plataforma (I4). La metodologı́a de TERESA recomienda empezar por hacer
descripciones de las tareas, e.g., “apagar la luz”.
Los modelos transitorios corresponden a los modelos de tareas y de conceptos (T1), IU
abstracta (T2) e IU concreta (T3). En el caso de PetShop, este sólo implementa el modelo
de conceptos, el cual es generado a partir de los modelos de conceptos (I1) y de aplicación.
La IU abstracta es generada mediante los modelos de presentación y de diálogo.
Capı́tulo 3
49
SEESCOA incluye sólo las interfaces de usuario (T2-T4) en la etapa de modelos transitorios;
la IU abstracta (T2) es generada a partir de los modelos de presentación, de diálogo, de
plataforma y de Dispositivos. En esta herramienta no se incluye el modelo de tareas debido
a que las tareas de un usuario no cambian durante el proceso de adaptación.
TERESA genera el modelo de conceptos y de tareas (T1) mediante los modelos de
conceptos (I1) y tareas (I1) pertenecientes a los modelos Iniciales. La IU abstracta (T2) es
generada a partir de los modelos de presentación, de diálogo y de plataforma, e.g., para la
tarea de “apagar la luz”, la selección del objeto de interacción (comando de voz o interacción
gráfica) se lleva a cabo la IU abstracta (T2), mientras que la selección tanto de la plataforma
como de la modalidad, se lleva a cabo en la IU concreta (T3).
La generación de la interfaz de usuario (abstracta, concreta o final) del marco RUIUMO puede ser automática (sin que intervenga un humano), manual (el humano realiza dicha
actividad) o semi-automática (generada tanto por la herramienta como por el humano). Las
tres herramienta presentadas permiten la intervención tanto del sistema como del humano en
la creación de algunas de las interfaces de usuario, en especı́fico en la IU abstracta (T2).
Tanto SEESCOA como TERESA ofrecen diferentes vistas de la misma IU, permitiendo que el
desarrollador elija la más apropiada.
Dos de las herramientas analizadas, PetShop y TERESA, proponen analizar y estructurar la
IU final (T4) en la etapa de diseño. Por otro lado, SEESCOA es la única herramienta que
implementa la generación de interfaces de usuario en tiempo de ejecución.
Es importante destacar que tanto SEESCOA como TERESA consideran la adaptación del
contexto de uso a nivel de plataforma en la etapa de diseño, además de considerar la multimodalidad.
3.2
CAMELEON-RT
CAMELEON-RT es un módulo arquitectural de referencia conceptual que soporta la distribución y la migración de la interfaz de usuario en grupos dinámicos heterogéneos, los cuales se
refieren a conjuntos de computadoras que soportan la incorporación y el retiro de dispositivos
sin afectar a la tarea en curso [Balme et al., 2004].
3.2.1
Capas de sistemas interactivos, DMP y plataforma
CAMELEON-RT está estructurado en tres niveles de abstracción (cf. Figura 3.2): en la parte
superior se encuentra la capa de sistemas interactivos; en la parte media se observa el núcleo
de la arquitectura, la cual contiene el middleware Distribución-Migración-Plasticidad
(middleware DMP) y, finalmente, en la parte inferior está la capa de plataforma.
50
Capa de sistemas interactivos
Sistema interactivo
Meta- IU
Infraestructura de contexto
Capa DMP
Herramientas
de
interacción
Administrador
de plataforma
Observador de sistema interactivo
Observador de
usuario
Observador de
plataforma
Configurador
Sintetizador
de situación
Motor de
evolución
Observador de
lugar físico
Identificador de situación
Administrador de
componente
Herramientas
para abstracción,
traslación y
concretización
Espacio de
almacenamiento
Productor de
adaptación
SO 4
SO 5
Administrador de adaptación-abierta
Capa plataforma
Sistema operativo
SO 1
SO 2
SO 3
Hardware (sensores, actuadores, superficies, ...)
Figura 3.2: Estructura del modelo arquitectural de referencia CAMELEON-RT
La capa de plataforma incluye tanto el hardware como el sistema operativo. El hardware
se refiere a una variedad de entidades fı́sicas, e.g., superficies e instrumentos, capacidad de
procesamiento y servicios de comunicación, ası́ como sensores y actuadores.
La capa de sistemas interactivos incluye los sistemas interactivos (e.g., una aplicación
CamNote y una meta-interfaz de usuario) que los usuarios ejecutan en un espacio interactivo.
La Meta-Interfaz de Usuario (Meta-IU) vincula las actividades que se pueden realizar en el
espacio interactivo y proporciona a los usuarios los medios para configurar, controlar y evaluar
el estado de dicho espacio.
La capa middleware DMP satisface tres requisitos: el modelado del espacio fı́sico, los
grupos dinámicos heterogéneos y la adaptación de la interfaz de usuario (cuando ocurre la
redistribución o la migración). A cada requisito mencionado le corresponde un servicio de
la capa DMP: una infraestructura de contexto, un administrador de plataforma,
herramientas de interacción y un administrador de adaptación-abierta (se dice que
una interfaz de usuario es adaptativa-abierta si provee un mecanismo de administración).
Capı́tulo 3
51
La infraestructura de contexto permite al espacio interactivo crear y mantener un modelo del lugar fı́sico. Está infraestructura genera información contextual en el apropiado nivel de
abstracción, a partir de los sensores de datos y de los eventos del sistema operativo.
Tanto el administrador de plataforma como las herramientas de interacción tienen el
mismo papel funcional del entorno de X-Windows 2 , con la diferencia de que amplı́an los grupos
heterogéneos dinámicos. La ampliación de dichos grupos incluye: a) apoyar el descubrimiento
de dispositivos, b) ocultar la heterogeneidad de los sistemas operativos y del hardware y c)
apoyar la redistribución y la migración de las interfaces de usuario.
El administrador de adaptación-abierta incluye observadores que proporcionan información contextual apropiada a un sintetizador de situación, cuyo rol es informar al motor
de evolución sobre la aparición de una nueva situación que puede requerir una adaptación
abierta. En caso de que se requiera tal adaptación, el motor de evolución utiliza los componentes recuperados del espacio de almacenamiento, además de un configurador para producir una nueva interfaz de usuario.
Los observadores sirven como puertas entre el entorno y el sintetizador de situación.
El observador de plataforma reúne información relacionada con los dispositivos (e.g., llegada y salida de una PDA o acoplamiento de dos superficies) mediante la suscripción de los
componentes del contexto para conocer la evolución de la plataforma.
El observador de lugar fı́sico mantiene un modelo del lugar fı́sico (e.g., ubicación de un
usuario en la sala R o en la calle S). Por otro lado, el observador de usuario se enfoca en
los usuarios, e.g., su perfil o su posición relativa a una superficie vertical. El observador de
sistemas interactivos se suscribe a información relevante para la plastificación de sistemas
interactivos.
El sintetizador de situación recopila información de la situación actual, la cual es proporcionada por los observadores. Una situación se define por un conjunto de observadores que
satisface un conjunto de predicados.
El motor de evolución genera una reacción en respuesta a una nueva situación mediante un
grafo de situaciones. La reacción puede ser una combinación de las especificaciones indicadas
por los desarrolladores y/o los usuarios (mediante una Meta-IU) o adquirida por dicho motor
de evolución.
El configurador ejecuta la reacción expresada por los desarrolladores; si se necesitan nuevos
2
X-Windows está enfocada en dotar a los sistemas UNIX de interfaces de usuario, dicho planteamiento
surgió alrededor del año 1984. Este sistema permitı́a a las aplicaciones un despliegue mediante la red sobre
dispositivos independientes, haciendo transparente la red. X-Windows tiene tres principales componentes: 1) el
administrador de ventanas se encarga de controlar el tamaño y los atributos de las ventanas y de remplazar
la ventana de una aplicación, 2) el administrador de entradas implementa el resto de la interfaz, i.e., este
controla qué aplicación ve la entrada de cierto dispositivo y 3) el sistema windows base se encarga de construir
y pasar los parámetros necesarios a las aplicaciones, al administrador de ventanas y al administrador de entradas
[Gettys and Packard].
52
componentes, estos son recuperados del espacio de almacenamiento por el administrador
de componentes.
3.2.2
Implementación
Por medio de CAMELEON-RT se crearon dos casos de estudio, los cuales son CamNote (por
CAMELEON Note) y I-AM (Interaction Abstract Machine). Como se mencionó en el capı́tulo
2, el primero es un visualizador de diapositivas que se ejecuta en plataformas heterogéneas
dinámicas, pocket PC y PC. La aplicación CamNote puede ejecutarse por completo en una
PC o bien puede dividirse entre los dispositivos mencionados. I-AM es un administrador de
plataforma que en esencia es similar a X-Windows, pero soporta grupos dinámicos heterogéneos.
A continuación se describen los componentes de las capas de CAMELEON-RT que se utilizaron
estos casos de estudio:
Respecto a la capa de plataforma, CamNote considera diferente dispositivos PC y pocket
PC (hardware), en tanto que I-AM considera diferentes sistemas operativos (software);
En cuanto a la capa de sistemas interactivos, CamNote implementa una Meta-IU, la cual
permite al usuario evaluar la migración y el proceso de adaptación del panel de control;
Como se mencionó en la sección 3.2.1, la capa middleware DMP está formada de tres grupos
de componentes: dentro de esta capa se tienen tres grandes grupos: 1) la infraestructura
de contexto, 2) el administrador de plataforma y un conjunto de herramientas de
interacción, y 3) un administrador de adaptación-abierta. Respecto a esta capa, IAM sólo implementa el segundo grupo de componentes, ya que posee una infraestructura para
descubrir cambios en la plataforma, oculta la heterogeneidad del hardware (PC y PDA) y soporta la migración de la interfaz de usuario. Por otro lado, CamNote implementa los siguientes
componentes del tercer grupo: el motor de evolución mediante reglas determinadas por el
desarrollador y el configurador de situación a través de una técnica de recuperación de datos.
Además, CamNote crea una nueva situación (a partir del sintetizador de situación) en
respuesta a la llegada o salida de una pocket PC.
3.3
Marco de Plasticidad Implı́cita
El marco de Plasticidad Implı́cita (PI) [Sendı́n and Collazos, 2006] tienen como objetivo incorporar plasticidad y conciencia de grupo en sistemas colaborativos, a partir del desarrollo de
una plantilla genérica y adaptable denominada IPE (Implicit Plasticity Engine). El concepto
de “plasticidad implı́cita” se refiere a la adaptación dinámica de la interfaz de usuario de un
sistema colaborativo cuando un usuario cambia a un nuevo contexto de uso, e.g., cambios en
el nivel de la luz de dı́a, en el ancho de banda de la red o en la localización del usuario. Los
cambios en la interfaz de usuario se pueden resolver mediante un reajuste automático en el lado
Capı́tulo 3
53
del cliente, sin requerir ninguna petición dirigida al servidor [Sendı́n and Lorés, 2004].
La plantilla IPE ofrece un mecanismo en tiempo de ejecución con la capacidad de: 1)
detectar el contexto y 2) adaptar la interfaz de usuario a cambios contextuales. De esta forma,
IPE provee una adaptación pro-activa del lado del cliente.
El objetivo del marco es proporcionar una retro-alimentación sin discontinuidades durante
el proceso de adaptación plástica, manteniendo ambos lados (cliente y servidor) en continua
actualización. Bajo este enfoque, el cliente sólo recurre al servidor cuando necesita reconfigurar
una interfaz de usuario no resuelta localmente por IPE. Para realizar dicha reconfiguración,
el cliente envı́a al servidor los cambios contextuales que requieren adaptaciones a la nueva
situación.
La platilla IPE se divide en tres capas:
1. la capa lógica contiene el núcleo funcional de la aplicación;
2. la capa de aspectos es una capa intermedia responsable de aplicar la adaptación sobre
el núcleo funcional según el modelo contextual (capa de conciencia de contexto).
Desde el punto de vista de la colaboración, la capa de aspectos debe comunicar eventos
y acciones para mejorar las actividades de grupales;
3. la capa de conciencia de contexto permite controlar y modelar condiciones en tiempo
real (modelo contextual); en el caso de los sistemas colaborativos, esta capa es responsable
de administrar toda la información relacionada con la comunicación y la coordinación que
afectan al grupo.
Hasta el dı́a de la publicación del artı́culo, los autores reportan que están desarrollando el
soporte colaborativo del lado del servidor, por lo tanto no existe ninguna implementación de
este marco.
3.4
Marco de Plasticidad Explicita Colaborativa
Sendin et al. proponen un marco conceptual llamado Plasticidad Explicita Colaborativa (PEC).
La plasticidad explicita [Sendı́n and Lorés, 2004] es la capacidad de generar automáticamente
una IU especı́fica para un contexto de uso, empezando de una especificación abstracta. Para
logar la generación automática de dichas interfaces se requiere de una maquina EPE (Explicity
Plasticity Engine), en la etapa de diseño [Sendı́n and Collazos, 2006].
Este marco se ubica del lado del servidor para llevar a cabo las adaptaciones necesarias
cuando el cliente haya iniciado una sesión o solicite una nueva adaptación.
54
Este marco aborda tres puntos: 1) conciencia de grupo como un parámetro de la plasticidad,
2) integración de un mecanismo de conciencia tanto del lado del cliente como del lado del
servidor y 3) integración de una vista general del conocimiento compartido. Este último se
refiere a todos los aspectos del trabajo colaborativo que pueden ser usados en el desarrollo de
una actividad grupal [Sendin et al., 2008].
3.4.1
Fases ARP, CRP, IMP y PIM
EL marco PEC se divide en cuatro fases: 1) Abstract Rendering Process (ARP), 2) Concrete
Rendering Process (CRP), 3) Implementation (IMP) y Preparation of the Initial Models (PIM).
La fase PIM contiene los repositorios necesarios para llevar a cabo la adaptación, e.g., DialogueM, TaskM, DominioM y SpacialM. La fase ARP genera la Interfaz de Usuario Abstracta
(concrete UI) usando los siguientes modelos: TaskM, DominioM, SpacialM, UserM, DialogueM
y GroupM. La fase CRP obtiene la Interfaz de Usuario Concreta (IU concreta) a partir de la
abstract UI; ésta fase selecciona los componentes concretos de la IU que mejor representan
la funcionalidad descrita por los componentes abstractos. Finalmente, la fase IMP genera la
Interfaz de Usuario Final (IU final) a partir de la IU concreta y regresa la IU final como código
ejecutable o interpretable. Las fases ARP, CRP e IMP se componen de varios modelos, los más
representativos se mencionan a continuación (cf. Figura 3.3):
• TaskM: es una representación estructurada de las tareas que un usuario puede llevar a
cabo mediante una interfaz de usuario;
• DomainM: denota los objetos relacionados con la tarea de un usuario;
• UsuarioM: representa las caracterı́sticas y los aspectos relacionados con un usuario, tales
como el nivel de conocimiento, preferencias, objetivos, situación, necesidades, etc.;
• DialogueM: se utiliza para describir la conversación entre una persona y una computadora.
El modelo de diálogo permite establecer el estilo de navegación;
• SpatialM: es una descripción detallada del mundo real que proporciona conciencia de
ubicación;
• PlatformM: e refiere a una expresión explı́cita de la plataforma de interacción en términos
de recursos fı́sicos y caracterı́sticas de software (e.g., sistema operativo, versión de la
máquina virtual de Java y configuración);
• EnvironmentalM: considera el tiempo (e.g., hora y dı́a de la semana) y las condiciones
ambientales (e.g., luz del dı́a, nivel de ruido ambiental y condiciones meteorológicas) que
son especı́ficos para cada dominio de aplicación y que influyen en la adaptación;
Capı́tulo 3
55
Figura 3.3: Marco conceptual de Plasticidad Explicita Colaborativa
• GroupM: es una representación del conocimiento compartido; en este modelo se considera
una memoria de grupo, la cual se puede conceptualizar como una colección de percepciones
individuales (conciencia de grupo).
El marco PEC se compone de los modelos previamente mencionados y de los niveles de
abstracción enlistados a continuación [Calvary et al., 2003, Sendin et al., 2008]:
1. abstract IU : es la interpretación de los conceptos de domino y funciones, los cuales son
independientes de los interactores. Esta interfaz de usuario es generada en la fase ARP;
56
2. concrete IU: hace explı́cita la interfaz de usuario final, aunque esta solo se ejecute dentro
del entorno de desarrollo en el que fue creada, e.g., para visualizar una interfaz de usuario
que no es ejecutable. La fase CRP obtiene esta interfaz de usuario a partir de la abstract
UI;
3. final IU: es generada a partir de la concrete IU), la cual es expresada en código fuente,
e.g., Java y HTML. Esta interfaz de usuario puede ser interpretada o compilada como una
interfaz de usuario pre-calculada, además de que es lanzada en ejecución en el entorno de
desarrollo en donde fue creada. La fase que se encarga de generar la final IU es IMP (cf.
Figura 3.3) ya que transforma el aspecto visual y dinámico de la concrete UI en código
ejecutable.
El marco PEC no solamente utiliza modelos y niveles de abstracción, sino también emplea
componentes, e.g., el modelo repositorio permite compartir conceptos, en tanto que el modelo
de transformación describe la conversión de la abstract UI a la concrete UI . Asimismo,
este marco maneja reglas de colaboración para informar cuando el servidor recibe una solicitud
de un miembro del grupo.
3.4.2
Implementación
Una implementación del marco PEC es la herramienta AB-UIED que soporta casi todos los
componentes del marco, excepto los relacionados con el soporte de la colaboración (e.g., modelo
de grupo) [Sendin et al., 2008]. Algunos de los modelos implementados en AB-UIED son los
siguientes:
• TaskM: usa tres diferentes notaciones, tales como diagrama de estado, modelo CTT,
además de una herramienta de interacción abstracta;
• concrete UI: usa UMLi (Unified Modeling Language for Interactive Applications);
• concreta UI : usa UsiXML (User Interface eXtensible Markup Language);
• final UI : es realizada por un traductor;
• Usability criteria: describe el peso y la importancia de cada criterio de usabilidad.
3.5
Marco para la Adaptación de la Conciencia de Contexto en Despliegues Públicos
El propósito de este marco [Cardoso and José, 2009] es orientar a los diseñadores en la creación
de despliegues públicos que ofrezcan la información correcta en el momento adecuado. Dentro
Capı́tulo 3
57
de las organizaciones, los despliegues públicos se han utilizado para facilitar las tareas, la
sincronización grupal, el trabajo cooperativo, la construcción de una memoria individual y
grupal, etc. [Churchill et al., 2004].
Este marco pretende lograr su objetivo mediante la relación de tres fases: huellas
digitales, Datos y Adaptación. La adaptación contextual comienza por la fase huellas
digitales (cf. componentes Hd1.1-Hd4 de la Figura 3.4), la cual se puede expresar como un
conjunto de datos en la fase de Datos (cf. componentes D1-D4 de la Figura 3.4) que sirven para
realizar la adaptación en la fase de Adaptación (cf. componentes A1-A4 de la Figura 3.4). En
particular, los componentes A1-A4 del proceso de adaptación son sólo sugerencias que pueden
ser remplazadas por los diseñadores.
Huellas digitales
Caracterización
de la presencia
(Hd1.1)
Identificación de
la presencia
(Hd1.2)
Enriquecimiento
de la presencia
(H2)
Datos
Patrón de
presencia
(D1)
Patrón de
presencia
individual
(D2)
Adaptación
Adaptación dependiendo ciertas
características, e.g., género y edad.
(A1)
Adaptación individual, e.g., no
mostrar el contenido previamente
visto por el usuario.
(A2)
Sugerencia de
contenido
(Hd3)
Palabras claves
(D3)
Adaptación combinando la presencia
individual y palabras claves, e.g.,
mostrar deportes cuando la mayoría
de usuarios estén interesados.
(A3)
Detección de
reacción
(Hd4)
Popularidad de
los elementos
(D4)
Adaptación al mostrar automáticamente contenido de interés en
cierto lugar.
(A4)
Figura 3.4: Marco para la Adaptación de la Conciencia de Contexto en Despliegues Públicos
Particularmente, la fase huellas digitales hace referencia al historial generado de las interacciones implı́citas o explicitas de un usuario con un despliegue público. Dichas interacciones
pueden ser de diferentes tipos, e.g., palabras claves, presencia, contenido, retro-alimentación de
contenido y perfiles personales. Cordoso y José se enfocan en los siguientes cuatro componentes
de la fase de huellas digitales (Hd): presencia (Hd1.1 y Hd1.2), presencia enriquecida
(Hd2), sugerencia de contenido (Hd3) y detección de reacción (Hd4).
Tanto la caracterización de presencia (Hd1.1) como la Identificación de presencia
(Hd1.2) pertenecen a la huella digital de presencia. En este marco, la presencia se refiere a la
habilidad de colectar información relacionada con las personas cercanas a un despliegue, ası́
que el componente Hd1.1 considera varios aspectos, e.g., la cantidad de personas, la edad y
el género de dichas personas, periodos de alta y baja actividad en el lugar y la presencia de
personas con ciertas caracterı́sticas.
El mecanismo de interacción que puede usarse para generar el componente Hd1.1 es el de
58
detección facial. Una vez obtenida la caracterización, se puede aplicar algún Patrón de presencia
(D1) para realizar algún tipo de Adaptación A1, e.g., suponiendo que la audiencia se caracteriza
por género, se puede desplegar información relevante para mujeres cuando la mayorı́a de la
audiencia sea del género femenino.
La Identificación de presencia (Hd1.2) es la habilidad de detectar quién está presente,
ya que esto permite asignar una única identidad. El enriquecimiento de la presencia
(Hd2) se refiere a la habilidad de obtener información acerca de los intereses, preferencias y
actividades de las personas cercanas a un despliegue. Los posibles mecanismos de interacción
que generan tanto la identificación como la presencia son los de detección por Bluetooth o RFID
(Identificación por Radio Frecuencia), con la diferencia de que el componente Hd2 requiere que
ambas detecciones proporcionen, adicionalmente el perfil del usuario, en cambio el componente
Hd1.2 no requiere dicho perfil. Otra forma de generar el componente Hd2 es mediante software,
e.g., obtener dicha información de páginas personales o de un conjunto de intereses previamente
establecidos en algún sitio de Internet.
Una vez obtenida la identificación de la presencia se puede implementar el patrón individual
de presencia (D2), el cual permite a los sistemas de despliegue minimizar la repetición del
contenido visto por cada usuario o identificar en qué periodos de tiempo se encuentra la misma
persona, ası́ como establecer una correlación entre diferentes personas o grupos (cf. componente
de adaptación A2).
En este marco, la sugerencia de contenido (Hd3) permite que los usuarios intervengan de
manera implı́cita, ya que ellos clasifican el contenido dependiendo del lugar. Dicho contenido
lo provee el usuario de manera directa al enviarlo (e.g, imágenes o audio) o de manera indirecta
mediante un URL.
La detección de reacción (Hd4) se refiere a la habilidad de detectar la reacción de los
usuarios hacia cualquier acción sugerida por un despliegue. Los mecanismos de interacción
para los componentes Hd3 y Hd4 pueden ser el correo electrónico, el servicio de mensajes
cortos (SMS por su siglas en inglés) y la tecnologı́a Bluetooth. Ambos componentes (Hd3 y
Hd4) utilizan los mismos mecanismos, solo que el primero los utiliza para proveer el contenido
y el segundo para enviar comandos de texto. Otra diferencia radica en que el componente Hd4
puede utilizar otros mecanismos, e.g., una pantalla táctil para proveer la reacción mediante
una interfaz gráfica de usuario y RFID para detectar la reacción mediante la proximidad a un
despliegue.
Las Palabras claves (D3) se pueden obtener a partir del enriquecimiento de la
presencia (Hd2), de la sugerencia de contenido (Hd3) y de la detección de reacción
(Hd4), mientras que la popularidad de elementos (D4) puede ser generada a partir de la
detección de reacción (Hd4).
El componente de adaptación (A3) puede ejecutarse al combinar el patrón individual
de presencia (D2) con las Palabras claves (D3) para que el sistema de despliegue pueda
seleccionar el mejor contenido para una preferencia individual, e.g., si algunas personas expresan
Capı́tulo 3
59
su interese respecto a un deporte, entonces el sistema podrı́a mostrar el contenido relacionado
con ese deporte en un momento dado.
El componente de adaptación (A4) tiene como objetivo proporcionar elementos similares en
las personas. Esta adaptación permite al sistema encontrar intereses de contenido, sin necesidad
de que los usuarios los expresen de manera explicita.
Hasta la fecha no se han implementado casos de prueba para este marco.
3.6
Marco y Arquitectura para Recomendaciones de
Conciencia de Contexto Grupal
El marco para Recomendaciones de Conciencia de Contexto Grupal (RCCG) provee sugerencias
de contexto tanto para modo grupal como para modo individual. Este marco está implementado
mediante una arquitectura cliente-servidor [Hussein et al., 2010].
La arquitectura propuesta se denomina Vistas de Contexto Hybreed. Hussein et al. incluyen
el término “vista de contexto” para referirse a un estado virtual que se genera a partir de
una secuencia de operaciones de contextualización. El contexto se refiere a incluir información
externa a las circunstancias (e.g, tiempo y lugar) como información derivada de la interacción
de los usuarios con el sistema (e.g., descargas e historial de navegación).
La arquitectura Vistas de Contexto Hybreed está representada mediante un diagrama de
clases que contiene los siguientes elementos: AgenteDeContexto, AdministradorDeEstado,
MecanismoDeSensado, MecanismoDeVista, Vista, RepositorioDeEstado y AdaptadorFinal,
de las cuales MecanismoDeSensado, FlujoDeTrabajo y la AdaptadorFinal son interfaces (cf.
Figura 3.5).
AdaptadorDePuntoFinal
0..*
MecanismoDeVista
0..*
Vista
1
FlujoDeTrabajo
1
0..*
AgenteDeContexto
AdministradorDeEstado
RepositorioDeEstado
1
MecanismoDeSensado
Figura 3.5: Diagrama de clases de la arquitectura Vistas de Contexto Hybreed
La clase AgenteDeContexto es responsable de procesar las peticiones del usuario.
60
La clase AdministradorDeEstado tiene como responsabilidad administrar el estado individual o grupal de los usuarios, e.g., si la ubicación de un usuario ha cambiado o si un usuario
dio clic sobre un cierto ı́cono. Esta clase (ubicada en el servidor) recibe la notificación, por
parte de un cliente, acerca de algún cambio en el estado actual de un usuario, lo cual implica
la actualización de dicho estado. La clase AdministradorDeEstado también puede recibir la
petición del estado global de un grupo. Dicha solicitud implica que el servidor solicite el estado
de cada cliente. Debido a que el estado global es la suma de los estados individuales, Hussein
et al. sugieren un mecanismo de bloqueo para evitar un problema de concurrencia. Dependiendo de la configuración realizada por los desarrolladores, el evento de actualización podrı́a
desencadenar en el servidor algunas operaciones de inferencia.
La clase MecanismoDeSensado infiere información del estado, e.g., determina la localización
geográfica de un usuario a partir de la dirección IP proporcionada por el cliente.
La clase RepositorioDeEstado se encarga de almacenar estados individuales o grupales y
opcionalmente de guarda el contexto del grupo. En el caso del estado global de un grupo, el
repositorio podrı́a usar sentencias para representar el estado de un grupo. Dichos datos podrı́an
guardarse un servidor central.
La clase MecanismoDeVista habilita un proceso de contextualización cuando un cliente realiza
la búsqueda de un estado virtual.
La implementación de la interfaz FlujoDeTrabajo describe cómo un estado cambia dentro
de una contextualización. Hussein et al. proporcionan un ejemplo de flujo de trabajo para
ejemplificar algunas recomendaciones. Dicho ejemplo puede ser remplazado por algoritmos de
contextualización ya que estos no están incluidos en el marco.
Los algoritmos de recomendación que se implementaron para la arquitectura propuesta corresponden a:
• la denotación de elementos relevantes mediante reglas;
• la propagación de la activación se refiere al intercambio de información entre nodos, ya
que al activarse uno o más nodos se pueden llegar a activar nodos adyacentes que tienen
cierto grado de relación semántica con los primeros nodos;
• el filtro colaborativo considera varios métodos para transferir tanto la vista de contexto
como el trabajo a los colaboradores que forman parte de un grupo, considerando caracterı́sticas en común;
• las aproximaciones hı́bridas se refieren a la utilización de algunos de los algoritmos mencionados, e.g., uso de un filtro colaborativo para obtener ciertos elementos, los cuales
pueden utilizarse como mecanismo de activación en el algoritmo de propagación de la
activación.
Bajo este marco se implementó la arquitectura propuesta, ası́ como la librerı́a Hybreed
Capı́tulo 3
61
RecFlow. Dicha librerı́a es una implementación de la interfaz FlujoDeTrabajo, pero no se
reporta el desarrollo de alguna aplicación en especı́fico.
3.7
Marco Genérico de Contexto
El marco Genérico de Contexto (GC) es un marco conceptual para aplicaciones adaptativas al
contexto que considera aspectos internos y externos al sistema. También pretende combinar
parámetros individuales tanto en contextos cooperativos como en contextos diferentes. Este
modelo abarca la conciencia de contexto y la adaptación al contexto [Haake et al., 2010].
Haake et al. sugieren que antes de utilizar el marco GC se debe definir dos puntos: 1)
la situación en donde la adaptación es necesaria, y 2) las acciones de adaptación que deben
ejecutarse para mejorar la colaboración.
3.7.1
Capas de
adaptación
conocimiento,
estado,
contextualización
y
El marco GC está dividido en cuatro capas: de conocimiento, de estado, de contextualización y de adaptación (cf. Figura 3.6).
La capa de conocimiento es la base principal de este marco, cuyo objetivo es proveer
los fundamentos necesarios para representar tanto el modelo del dominio como los diferentes
aspectos de contexto, e.g., entorno fı́sico, dispositivos de cómputo y modelo del usuario. Esta
capa requiere de los siguientes componentes para lograr su propósito: modelo de dominio,
reglas de inferencia, conocimiento concreto y abstracto.
El conocimiento abstracto puede ser inferido del conocimiento concreto, e.g., una persona está en un cuarto (conocimiento abstracto), lo cual se deriva a partir del hecho que
Paúl está en el cuarto LF283 (Conocimiento concreto). Las reglas de inferencia son las
que se encargan de hacer la inferencia de un conocimiento a partir de otro.
El modelo de dominio tiene como función almacenar tanto el conocimiento abstracto
como el concreto, ası́ como enviar y recibir información de la capa de estado. A este nivel,
la información obtenida puede ser de varios tipos: de un usuario, de una situación independiente, información neutral, información del sistema o información externa estática, e.g., la
capital de un paı́s. Este modelo contiene varias clases para el manejo de la comunicación
sı́ncrona y ası́ncrona por medio de audio, video y chat, conciencia sı́ncrona y ası́ncrona, administración (e.g., sesión, concurrencia y usuario), ası́ como editores compartidos (texto, imagen y
calendario).
La capa de estado contiene información de la situación actual, del entorno fı́sico y computacional, recursos y un modelo del usuario, e.g., ¿en dónde está el usuario?, ¿qué hora es? y
62
Capa de adaptación
Reglas de
adaptación
Estado de
adaptación
Capa de contextualización
Reglas de
contextualización
Estado
contextualizado
Capa de estado
Reglas de sensado
Estado
Capa de conocimiento
Reglas de
inferencia
Conocimiento
concreto preConocimiento
abstracto
predefinido
Modelo de dominio
Figura 3.6: Marco Genérico de Contexto
¿cuál es la circunstancia actual? A este nivel se obtiene un modelo del estado actual, mediante
grafos de estado. Los componentes de esta capa corresponden a las reglas de sensado y el
modelo de estado.
Las reglas de sensado toman información interna y externa al sistema, ası́ como el
Conocimiento concreto mediante el modelo de dominio (ambos ubicados en la capa de
conocimiento) para reflejar el estado individual y sus propiedades.
La capa de contextualización provee técnicas que definen un subconjunto de un estado
que es relevante para cierto enfoque, el cual es un subconjunto no vació de objetos del modelo
de estado que representa en cierto momento, el centro de atención del sistema. El enfoque
sirve como entrada inicial para ejecutar las técnicas de contextualización. Los componentes en
esta capa corresponden a las reglas de contextualización (técnicas de contextualización)
y al estado de contextualización.
Las reglas de contextualización seleccionan aquellas partes de todo el estado que son
relevantes para el enfoque actual. La sentencia SI-ENTONCES se utilizó en esta capa,
e.g., SI (?Person 1 works on ?ProyectY) Y (?Person 2 works on ?ProyectY) Y (?Person 1
has pref com channel ?Com c) Y (?Person 2 has pref com channel ?Com c) ENTONCES
?Com c. La regla de contextualización infiere que ambos colaboradores tienen preferencia por el
mismo canal de comunicación (?Com c), el cual es agregado al estado de contextualización.
Capı́tulo 3
63
El estado de contextualización puede verse como un filtro, cuyo resultado es un grafo
por cada enfoque (e.g., usuario o grupo) que sirve para la adaptación.
Finalmente, la capa de adaptación contiene las reglas de adaptación que describen qué
acción de adaptación se ejecuta en qué caso. Las reglas de adaptación incluyen operaciones
para cambiar propiedades del entorno cooperativo o variables de estado (e.g., mostrar o iniciar
alguna aplicación). Como resultado de esta capa, la adaptación se refleja en la interfaz de
usuario.
3.7.2
Implementación
Haake et al., proponen algunos dominios de aplicación de los sistemas colaborativos, ası́ como
una serie de escenarios en donde puede aplicarse el marco propuesto.
Los dominios de los sistemas colaborativos están representados mediante diagramas de bloques. Los dominios considerados son: artefactos compartidos (imagen, documento, etc.), roles,
espacio de trabajo, tarea a resolver, actividades de los colaboradores y aplicaciones colaborativas.
Por otro lado los escenarios, representados mediante el lenguaje OWL (Web Ontology Language), están divididos respecto a situaciones cooperativas tales como co-localización, co-acceso,
co-recomendación y co-dependencia. Cada escenario ejemplifica la situación de dos personas
que colaboran en la redacción de un documento. A continuación se exponen los puntos importantes a considerar en cada escenario: la detección tanto de participantes colocalizados como
los dispositivos en uso (co-localización); la habilitación de funcionalidades en un sistema colaborativo dado el rol de un colaborador (co-acceso); la recomendación de información dada
una solicitud previa (co-recomendación), y la manipulación de tareas, e.g., la asignación automática o manual, las prioridades entre ellas, la fecha lı́mite y la dependencia entre ellas
(co-dependencia).
El proceso de adaptación de este marco sigue el ciclo tradicional de adaptación, el cual consiste
de las fases siguientes: acción del usuario, sensado, selección de la adaptación y ejecución de
la adaptación. Mediante este proceso se puede representar el proceso de adaptación del marco
CG de la siguiente manera:
• el sensado tiene como entrada la información proveniente del exterior e interior del sistema y del modelo de dominio (capa de conocimiento). Las entradas anteriores son
procesadas mediante reglas de sensado para generar o modificar el modelo de estado
(capa de estado);
• la selección de la adaptación está representada por la contextualización que tiene como
entrada el modelo de estado (capa de estado), el cual es procesada por las reglas de
contextualización cuya tarea es establecer el estado de contextualización (capa
de contextualización);
64
• la adaptación tiene como entrada el estado de contextualización (capa de contextualización), el cual es procesado por las reglas de adaptación (capa de
adaptación). Esta fase tiene como objetivo ejecutar la adaptación correspondiente,
e.g., mostrar información relacionada o encender/apagar un proyector.
El marco GC permite extender las aplicaciones colaborativas con adaptación al contexto.
La extensión se logra mediante una arquitectura conceptual (cf. Figura 3.7), la cual pretende
dar una opción para unir una aplicación colaborativa con un soporte de adaptación al contexto. En el lado derecho de dicha arquitectura, se muestran los componentes del marco CG,
mientras que en el lado izquierdo se representan los componentes de la aplicación a extender. El marco GC está compuesto por el módulo servidor de adaptación, el cual incluye
tres mecanismos (sensado, adaptación y contextualización) que representan el proceso
de adaptación mencionado en el párrafo anterior.
Capa de IU
IU de la aplicación
IU de la
aplicación 1
IU de la
aplicación 2
Componente
de adaptación
Capa de lógica
Servidor de adaptación
Lógica de la aplicación
Lógica de la
aplicación 1
Servicios
básicos
Lógica de la
aplicación 2
Notificador
Mecanismo
de sensado
Mecanismo
de adaptación
Mecanismo de
contextualización
Capa de servicio
Servicios
Servicios de contexto
Servicios de
aplicación
Servicios de
colaboración
Servicios del
MGC
Capa de modelo
Modelo de contexto
Repositorio compartido
Artefacto 1
Artefacto 2
Artefacto 3
Modelo del
MGC
Figura 3.7: Arquitectura conceptual del marco genérico de contexto
Capı́tulo 3
65
Otro módulo importante que contiene servicios del marco es el servicio de contexto,
el cual accede y manipula el módulo modelo de contexto. Este está conformado por los
diferentes modelos del marco, e.g., modelo de dominio, sensado de reglas y el estado.
En la arquitectura propuesta se debe habilitar primero el mecanismo de adaptación para
permitir cambios en las IU de la aplicación por medio del componente de adaptación.
Dicho componente llama a funciones de adaptación, las cuales son proporcionadas por los
desarrolladores de la aplicación. Después de habilitar el mecanismo de adaptación, se habilita
el mecanismo de sensado para monitorear la interacción del usuario con la aplicación y los
cambios en el entorno de cómputo mediante los servicios básicos, los cuales interceptan a
las llamadas de las interfaces desarrolladas y registradas previamente por los desarrolladores.
La notificación informa tanto a la lógica de la aplicación como al servidor de
aplicación acerca de los cambios relevantes de la configuración. El componente de
adaptación se encarga de iniciar o detener las IU de la aplicación, ası́ como de usar una
interfaz especı́fica para realizar la adaptación en el módulo mencionado. Las interfaces mencionadas permiten trabajar sobre los componentes de la interfaz gráfica de usuario, e.g., mostrar,
ocultar y modificar los componentes.
Los desarrolladores del marco GC implementaron la arquitectura conceptual propuesta, en
donde la IU de la aplicación funciona como plugins para el entorno de desarrollo Eclipse.
El prototipo reportado une la aplicación CURE (Collaborative Universal Remote Education) y
R-OSGi 3 para administrar tanto en espacios de trabajo como en documentos, además Haake et
al. proveer conciencia ası́ncrona y comunicación. Los servicios básicos se refieren al acceso
del usuario, a la administración de sesión, a la autenticación, al acceso a la base de datos y al
sensado.
Mediante la implementación de la arquitectura, Haake et al. consideran que su marco GC
puede ser operacional. No crearon una aplicación especı́fica, pero a partir de cuatro escenarios
propuestos, los cuales son relevantes porque denotan situaciones tı́picas del trabajo colaborativo (co-localización, co-acceso, co-recomendación y co-dependencia), se crearon pruebas
funcionales.
3.8
Análisis comparativo de los marcos analizados
En la Tabla 3.2 se analizan dos puntos importantes de los marcos revisados. El primer punto
es conocer si los marcos están diseñados para sistemas mono-usuario o colaborativos. En
este caso se aprecia que tanto el marco RUIUM-O4 como CAMELEON-RT se enfocan en
3
4
http://r-osgi.sourceforge.net/
Referencia Unificado para Interfaces de Usuario Multi-Objetivo
66
sistemas mono-usuario. En cambio, los marcos restantes (PI5 , PEC6 , ACCDP7 , RCCG8 y
GC9 ) se especializan en sistemas colaborativos, ya que el marco PI tiene como objetivo ofrecer
plasticidad y conciencia de grupo a los sistemas cooperativos, en cambio el marco PEC combina
la conciencia de grupo con la plasticidad. Por otro lado, el marco ACCDP pretende proveer
de adaptación de conciencia de contexto en despliegues públicos, en donde los despliegues
consideran el trabajo cooperativo.
Nombre del
conceptual
marco
Colaborativo
Nombre(s) de la
implementación
RUIUM-O
X
---
CAMELEON-RT
X
CamNote y I-AM
PI
V
---
PEC
V
AB-UIED
ACCDP
V
---
RCCG
V
librerı́as
GC
V
arquitectura
Tabla 3.2: Modelos conceptuales e implementación de los marcos estudiados
Es importante hacer notar que tanto el marco RCCG como el GC tienen la caracterı́stica de
abordar el trabajo individual o grupal, ya que el primero tiene como objetivo proveer recomendaciones para ambos ámbitos mencionados; en tanto que el marco GC aborda ambos ámbitos
ya que a partir de tomar en cuenta aspectos individuales, e.g., determinar la ubicación de cierto
usuario, puede formarse una idea grupal.
El segundo punto importante en la Tabla 3.2 es conocer si los marcos tienen algún tipo de
implementación. El marco RUIUM-O no implementa algún ejemplo de prueba, dicho marco se
probo al compararse con algunas herramientas previamente publicadas, las cuales siguen similar
5
Plasticidad Implı́cita
Plasticidad Explicita Cooperativa
7
Adaptación de Conciencia de Contexto en Despliegues Públicos
8
Recomendaciones de Conciencia de Contexto de Grupo
9
Genérico de Contexto
6
Capı́tulo 3
67
metodologı́a que la sugerida en dicho marco. Por otro lado, CamNote y I-AM son aplicaciones
creadas con base en el marco CAMELEON-RT. Dentro de los marcos cooperativos, el marco
PI se encuentra en vı́as de implementación, hasta el momento se encuentra en desarrollo la
parte del servidor. Mientras que bajo el marco PEC se reporta la herramienta AB-UIED que
permite la producción automática de interfaces plásticas, pero no para ambientes cooperativos
ya que no se implementaron los módulos concernientes al entorno cooperativo, e.g., el modelo
de grupo. Es importante hacer notar que con la herramienta AB-UIED no se reporta alguna
aplicación.
El marco RCCG fue implementado mediante librerı́as al igual que algunos algoritmos para
proveer la recomendación de conciencia de contexto, solo que no se reporta alguna aplicación
que haga uso de todas estas librerı́as. Por otro lado, Haake et al., autores del marco GC, implementaron la arquitectura propuesta para unir el marco GC con las aplicaciones cooperativas.
Ellos a partir de los escenarios reportados obtienen pruebas funcionales, las cuales son usadas
para probar la implementación de la arquitectura.
La implementación de interfaces de usuario plásticas multimodales generan un espacio del
problema, e.g., adaptación al contexto de uso, percutores de plasticidad, granularidad de la
interfaz de usuario, granularidad del estado de recuperación, etc. Hasta el momento, se consideran siete elementos que conforman el espacio del problema (cf. Sección 2.1).
Una de las siete dimesiones del espacio del problema de mayor relevancia para este trabajo
de investigación es la dimensión contexto de uso, la cual considera la adaptación al usuario,
al entorno y la plataforma sin perder usabilidad. Dicha dimensión se analiza en la tabla 3.3. El
marco RUIUM-O considera por completo la dimensión contexto de uso tanto en el modelo
Ontológico como en el arquetı́picos; en este marco se considera al usuario de manera general en
sus modelo Usuario, ubicado en los modelos ontológicos y arquetı́picos, pero podemos observar
que existe el modelo tareas para referirse a la tarea del usuario. En cambio, los modelos
plataforma permiten hacer la descripción de los componentes disponibles, ası́ como clasificarlos
en plataforma básica, e.g, computadora personal, o en clusters. Los modelos entorno contienen
caracterı́sticas genéricas para describir los entornos adyacentes.
El marco CAMELEON-RT abarca por completo el contexto de uso, i.e., considera al
usuario, el entorno y la plataforma. Dicho marco considera la plataforma, la cual esta compuesta por hardware (e.g., sensores y superficies de despliegue) y software (e.g., Sistema Operativo
(SO) y las aplicaciones en ejecución), mediante varios componentes del marco, e.g., la capa de
plataforma y el administrador, para anunciar la llegada o salida de algún dispositivo o informar
que sistema interactivo está ejecutando el usuario. También este marco, CAMELEON-RT,
abarca el entorno a partir de la infraestructura de contexto y el observador del lugar
fı́sico para proveer un modelo del lugar fı́sico; por último abarca al usuario por medio del
observador de usuario, el cual puede proveer información relevante, e.g., perfil del usuario,
la ubicación y posición relativa.
El marco PEC estima por completo el contexto de uso, ya que considera al usuario mediante varios modelos, e.g., usuario, dominio y tarea, para tener conocimiento de caracterı́sticas,
68
Marco
ceptual
con-
Usuario
Plataforma
Entorno
tareas
básica o
clusters
caracterı́sticas
genéricas del lugar
perfil y
ubicación fı́sica
software y
hardware
modelo del lugar
PI
no especifica
no especifica
no especifica
PEC
tareas,
preferencias,
nivel de
conocimiento,
objetivos y
situaciones
software y
contabiliza los
recursos fı́sicos
tiempo,
condiciones
ambientales y
meteorológicas
identifica y
enriquece la
presencia
no especifica
detección de
participantes
no especifica
proporcionar
trabajo a
miembros
aplicaciones y
dispositivos de
cómputo
artefacto,
detección de
participantes,
tiempo,
co-localización,
espacio de trabajo,
recomendación de
información
RUIUM-O
CAMELEONRT
ACCDP
RCCG
GC
estado grupal o
individual
preferencias,
grupos, tarea,
rol, acciones y
actividades
Tabla 3.3: Análisis de los marcos con relación al contexto de uso
e.g., conjunto de tareas que puede llevar a cabo el colaborador, preferencias, objetivos, nivel de
conocimiento, situaciones y necesidades. El PEC aborda la plataforma por medio del modelo de
plataforma para contabilizar los recursos fı́sicos ası́ como las caracterı́sticas de software. Final-
Capı́tulo 3
69
mente, el marco mencionado contempla él entorno usando el modelo espacial y el de ambiente
para obtener la descripción del exterior, de tal manera que se pueda obtener una conciencia de
ubicación, tiempo (hora y dı́a de la semana) y las condiciones ambientales (luz del dı́a, nivel de
ruido ambiental y condiciones ambientales y meteorológicas.
El marco GC también aborda totalmente la adaptación al contexto de uso mediante las
capas de conocimiento y estado; en la primera capa se infiere y se almacena los componentes del
contexto de uso, entorno, usuario, y plataforma; mientras que en la capa de estado se modela
el contexto de uso tomando información interna y externa al sistema ası́ como información de
la capa de conocimiento. Las capas anteriores, conocimiento y estado, detectan los cambios
en el contexto de uso. Este marco aborda de diferentes maneras la dimensión usuario, e.g, las
preferencias de los colaboradores con relación al canal de comunicación, como se menciona en
las reglas de contextualización (capa de contextualización); el artefacto que están los colaboradores manipulando en el momento, la formación de grupos, varios aspectos de la tarea:
la tarea a resolver, las prioridades entre ellas, el deadline, la dependencia entre ellas y la
asignación automática o manual; el rol y aspectos dependientes del rol: los permisos de acceso,
y las actividades de los colaboradores. En el caso de la dimensión plataforma se considera
las aplicaciones y el uso de diferentes dispositivos. Finalmente, este marco considera varios
aspectos de la dimensión entorno compartido, e.g., consideración del artefacto, detección de
participantes, tiempo (hora actual), co-localización, y las acciones permitidas en las aplicaciones
considerando el rol.
Tanto el marco ACCDP como el marco RCCG aborda parcialmente el contexto de uso ya
que no especifica la inclusión de la plataforma. El marco ACCDP se centra en el usuario ya
que detecta la presencia de los usuarios, e.g., edad, género y preferencias, mediante las huellas
digitales identificación y enriquecimiento. Mientras que el marco RCCG considera el estado
del usuario mediante las clases AdministradorDeEstado, MecanismoDeSensado entre otras para
inferir la ubicación o conocer el elemento seleccionado. El entorno es abordado por el marco
ACCDP ya que puede detectar la cantidad de personas en un lugar, el género, etc, sı́ como la
sugerencia de contenido de un grupo mediante las huellas digitales caracterización y sugerencia
de contenido. El marco ACCDP aborda el entorno cuando proporciona el trabajo a miembros
del grupo por medio de los algoritmos de recomendaciones.
Por último, el marco PI aborda la adaptación al contexto de uso basándose en IPE (Implicit
Plasticity Engine); en particular la adaptación se calcula en la capa de conciencia de contexto,
sin especificar a detalle a qué se adapta, e.g., nivel de luz.
El resto de las dimensiones del espacio del problema corresponden a percutores de
plasticidad, granularidad de la interfaz de usuario, granularidad del estado
de recuperación, despliegue, espacio tecnológico y Meta-IU.
El percutor de plasticidad considera la remodelación, la redistribución y la migración.
El marco RUIUM-O permite cambios de una plataforma a otra, e.g., de una PC hacia una
PDA, por medio del módulo procesamiento de la reacción ubicado en la evolución; por lo tanto
podemos decir que este marco implementa la migración, pero no especifica la implementación de
70
la remodelación ni de la redistribución. Por otro lado, el marco CAMELEON-RT implementa
parcialmente el percutor de plasticidad mediante su capa middleware, dicha capa soporta
la redistribución y la migración de la interfaz de usuario. En cambio, los marcos PI, PEC,
ACCDP, RCCG y GC solo mencionan la adaptación de la interfaz de usuario a cambios contextuales cuando sea necesario, pero no indican si esta adaptación se hace a nivel remodelación,
redistribución o migración.
La granularidad de la interfaz de usuario señala el grado en que la interfaz de usuario
ha sido metamorfoseada después de la adaptación. Dicha granularidad se clasifica en: nivel
aplicación, espacio de trabajo, interactor o pı́xel. En este caso todos los marcos analizados
modifican la interfaz de usuario, solo que no mencionan a que nivel de granularidad cambian.
La granularidad del estado de recuperación se refiere al grado de preservación del trabajo realizado por el usuario en el sistema antes de la adaptación plástica. Tres tipos de granularidad del estado de recuperación son posibles: acción, tarea y sesión. El marco RUIUM-O
considera la recuperación del estado mediante el epı́logo, perteneciente al modelo de evolución,
al restaurar el contexto de ejecución; ası́ que este marco considera la recuperación sin especificar a qué nivel, solo ejemplifican a nivel tarea. El resto de los marcos, CAMELEON-RT,
PI, PEC, ACCDP, RCCG y GC, no proporcionan indicios de soportar la granularidad del
estado de recuperación, aún cuando el marco PEC no especı́fica la implementación de dicha
granularidad ya considera almacenar información de cada miembro.
El despliegue indica el momento en que se realiza la adaptación de la interfaz de usuario,
i.e., la adaptación se realiza de manera estática, al momento de lanzar la aplicación, o de
manera dinámica, en tiempo de ejecución. Tanto el marco RUIUM-O como PI implementan un
despliegue a nivel dinámico; el primero lleva a cabo dicho despliegue mediante sus modelos
observadores que se encargan de describir la realidad, la cual puede ser usada para llevar a cabo
la adaptación, y el marco PI implementa el despliegue dinámico gracias a su plantilla IPE.
Los demás marcos, CAMELEON-RT, PEC, ACCDP, RCCG y GC, no proveen la información
necesaria para determinar el tipo de despliegue implementado.
El espacio tecnológico se refiere a la Ingenierı́a Dirigida por Modelos, que puede clasificarse en: intra-espacio, inter-espacios y multi-espacios. Todos los marcos conceptuales
(RUIUM-O, CAMELEON-RT, PI, PEC, ACCDP, RCCG y GC) no ofrecen suposición alguna
de permitir la implementación del espacio tecnológico; excepto RUIUM-O ya que considera
cambiar de código ejecutable cuando no sea soportado por el nuevo contexto, solo que no indica
si cambia o permanece en el mismo espacio tecnológico.
La Meta-interfaz de usuario (Meta-IU) indica al usuario el proceso de plasticidad y
comprende las siguientes categorı́as: con negociación, sin negociación, plástica e inexistente.
En el caso del marco RUIUM-O considera la Meta-IU con negociación, ya que el desarrollador puede intervenir en cualquiera de las interfaces de usuario (Abstracta, Concreta y Final)
generadas por el marco. Mientras que el marco CAMELEON-RT toma en cuenta la Meta-IU
con negociación en la capa de sistemas interactivos, ya que los usuarios pueden manipular el
espacio interactivo.Por otro lado, el marco PEC contempla el modelo diálogo para establecer
Capı́tulo 3
71
el estilo de navegación, dicho modelo puede considerarse como una Meta-IU con diálogo.
Finalmente, los marcos PI, PEC, ACCDP, RCCG y GC no proporcionan suficiente información
para determinar algún tipo de implementación de la Meta-IU
La sección de análisis termina con la tabla 3.4 para mostrar caracterı́sticas como tipo de
adaptación, variables contextuales y tipo de contexto.
Marco
ceptual
con-
Tipo de contexto
Variables
textuales
mono-entidad
el contexto
CAMELEONejecución
RT
mono-entidad
plataforma
PI
no especifica
multi-entidad
el contexto
PEC
no especifica
multi-entidad
IU inicial y por
petición
del
cliente
ACCDP
presentación
aumentación
multi-entidad
huellas digitales
RCCG
no especifica
multi-entidad
notificar o solicitar el estado
GC
no especifica
multi-entidad
el contexto
RUIUM-O
Tipo
adaptación
de
no especifica
y
con-
Tabla 3.4: Análisis de adaptación y contexto en los marcos presentados
El tipo de adaptación se forma por presentación de la información, ejecución automática
de un servicio e información aumentada. Los marcos RUIUM-O, PI, PEC, RCCG y GC no
especifican que tipo de adaptación puede llevarse a acabo, ya que este tipo lo define el desarrollador. En cambio, el marco CAMELEON-RT lleva a cabo un tipo de adaptación catalogada
como ejecución automática al llevar a cabo la redistribución o migración de la IU. El marco
ACCDP proporciona ejemplos de adaptaciones, los cuales cubren dos tipos de adaptación, la
primera corresponde a presentación de la información cuando se siguiere mostrar información
relevante a cierto grupo; la segunda pertenece a la información aumentada al mostrar información de interés en cierto lugar.
El tipo de contexto se refiere a considera una sola entidad, mono-entidad, o considerar
72
varias entidades de forma simultanea, multi-entidad. Aún cuando el marco RUIUM-O y el
marco CAMELEON-RT consideran múltiples variables contextuales, e.g., plataforma, entorno y
tareas, dicho marco son mono-entidad ya que se centra en satisfacer un solo usuario. Los marcos
restantes pertenecen a la clasificación multi-entidad; ya que los marcos PI y CG tienen como
objetivo mostrar la conciencia de grupo, mientras que el marco GC pretende proveer conciencia
de contexto grupal o individual. El marco ACCDP es multi-entidad porque considera tanto las
reacciones como las sugerencias de los usuarios presentes en un lugar, para proveer algún tipo
de adaptación. Finalmente, el marco RCCG implementan un contexto a nivel multi-objetivo
ya que considera los estados individuales de los usuarios para después generar un estado grupal.
Las variables contextuales son la variables relevantes consideradas para llevar a cabo
la adaptación. Los marcos RUIUM-O, PI y GC tienen una variable general, ya que ante
cualquier cambio en el contexto la adaptación tiene que llevarse a cabo. Por otro lado, el marco
CAMELEON-RT tiene como variable contextual la plataforma, ya que a partir de detectar
una plataforma puede migrar o distribuirse. En cambio, el marco PEC realiza la adaptación
para producir la IU inicial y cada vez que el cliente requiera la adaptación. El marco ACCDP
lleva a cabo la adaptación cuando ocurre cambio en algunas de las huellas digitales siguientes:
presencia, presencia enriquecida, sugerencia de contenido y detección de reacción. Por último,
el marco RCCG tiene como variables contextuales la actualización del estado de un usuario o
la solicitud del estado global.
3.9
Conclusiones
Los marcos descritos en esta sección fueron seleccionados debido a que implementan algunas
de los caracterı́sticas de las interfaces de usuario plásticas multimodales.
Dado el análisis de los marcos con respecto al contexto de uso se puede observar que existe la
tendencia en considerar varias peculiaridades del usuario , e.g., el perfil, las tareas asignadas y
el rol, con la finalidad de proveer una mejor adaptación. Las caracterı́sticas anteriores cada vez
consideran aspectos muy finos, e.g., las acciones realizadas dentro del sistema y las preferencias
respecto a un tema. Por otro lado, la adaptación a la plataforma se centra en acoplarse a
las caracterı́sticas que ofrece cada dispositivo de cómputo, pero la tendencia en este punto es
considerar sensores para permitir la conciencia del entorno fı́sico, además de crear clusters de
manera dinámica con los dispositivos al alcance de los usuarios. En cuanto la adaptación al
entorno, los marcos están tendiendo a modelar el entorno fı́sico, e.g., detectar las personas en
un lugar, ası́ como proporcionar información relevante a cada usuario.
Retomando los puntos relevantes de las interfaces de usuario plásticas se observa que los
marcos se inclinan por permitir que los usuarios finales intervengan en la adaptación mediante
una META-IU, ası́ como llevar la adaptación en tiempo de ejecución, dejando de lado los demás
puntos a considerar.
Capı́tulo 4
Análisis de requerimientos del marco
XARE
En este capı́tulo se presenta una definición del contexto de uso de los sistemas mono-usuario
que sirve de base para definir el contexto de uso de los sistemas colaborativos (cf. Sección 4.1).
Una vez definido este último concepto se puede hacer uso de términos como grupo de colaboradores, conjunto de plataformas y entorno común, los cuales serán usados en varios escenarios
que involucran procesos adaptativos. Dichas adaptaciones no han sido consideradas en el estado
del arte analizado en los capı́tulos 2 y 3. Para dar una idea más clara de los requerimientos
evidenciados en dichos escenarios, se proponen varias aplicaciones, algunas de las cuales son
reutilizadas en varios escenarios (cf. Sección 4.2).
Posteriormente, cada escenario contiene tres partes: 1) un preámbulo, 2) un objetivo y 3)
una aplicación. El preámbulo proporciona brevemente las posibles adaptaciones del escenario,
por otra parte el objetivo proporciona la idea general, mientras que la aplicación ejemplifica
un entorno en donde se usa el escenario, el cual evidencia el contexto de uso de los sistemas
cooperativos involucrados (cf. Sección ??).
Las aplicaciones desarrolladas, a partir de los escenarios, parten de un conjunto de requerimientos funcionales y no funcionales. Después se presentan los requerimientos de las aplicaciones,
estas están acompañadas de las interfaces de usuario, ası́ como de las variables contextuales
que provocan la adaptación de dicha aplicación (cf. Sección 4.10).
Finalmente, se muestran las conclusiones obtenidas de este capı́tulo (cf. Sección 4.11).
73
74
Análisis de requerimientos del marco XARE
4.1
Contexto de uso
La movilidad de las personas junto con el desarrollo de una amplia variedad de dispositivos de
acceso han engendrado nuevos requerimientos en el campo de investigación de la Interacción
Hombre-Máquina (IHM), tales como la capacidad de los sistemas interactivos para ejecutarse
en diferentes contextos.
Probablemente la definición de contexto más referenciada es la que proponen Dey et. al, la
cual dice [Dey et al., 2001]:
“Contexto es alguna información que puede ser usada para caracterizar la situación
de una entidad. Una entidad es un usuario, un lugar, un objeto fı́sico o de cómputo
que es considerado relevante para la interacción entre un usuario y la aplicación,
incluyendo al propio usuario y a dicha aplicación.”
4.1.1
Recapitulación del contexto de uso de los sistemas monousuario
Retomando la definición de plasticidad de las interfaces de usuario de los sistemas mono-usuario
[Calvary et al., 2006], del capı́tulo 1, la cual refiere que:
La plasticidad es la capacidad de las interfaces de usuario de adaptarse a cambios
en el contexto de uso, preservando un conjunto de criterios de calidad, como la
usabilidad.
Por contexto de uso se entiende la terna <usuario, plataforma, entorno> donde el
usuario denota el arquetipo humano que tiene por objeto utilizar el sistema interactivo
[Vanderdonckt, et al., 2008]. El elemento usuario contiene varios componentes, algunos de
ellos son los siguientes: perfil, actividad [Coutaz and Calvary, 2008] y rol. Los componentes
anteriores funcionan como factores externos al sistema, ya que cambian según el usuario y
pueden llegar a modificar el conjunto de funcionalidades que ofrece el sistema.
En el ámbito de los sistemas mono-usuario los factores anteriores (perfiles, actividades y
roles) han sido estudiados por los desarrolladores de software. Algunos de los estudios se han
enfocado en adaptar las funcionalidades de un sistema a diferentes perfiles de usuario. La
adaptación se lleva a cabo de manera personalizada, ya que las necesidades y preferencias
de un usuario solo afectan a la instancia del sistema que él está ocupando, sin afectar a las
instancias de los demás usuarios. Algunos ejemplos de este tipo de adaptación serı́an informar
a los usuarios de una librerı́a sobre la llegada de nuevo material según el perfil de cada uno de
ellos [Amato and Straccia, 1999] y permitir a los usuarios decidir la manera en que desean ser
contactados dada una situación determinada [Stan et al., 2008].
Capı́tulo 4
75
El elemento plataforma se refiere a los dispositivos de hardware y software disponibles
para sostener la interacción del usuario con el sistema. La plataforma puede ser modelada
en términos de los recursos computacionales que determinan la forma en que se procesa, se
transmite y se presenta la información, ası́ como la manera en que el usuario manipula la
información. Comúnmente el tamaño de la memoria, el ancho de banda de la red y la plataforma
de interacción motivan la selección de un conjunto de modalidades de E/S y la cantidad de
información disponible [Calvary et al., 2004, Calvary et al., 2001].
El elemento entorno describe las condiciones fı́sicas y sociales donde tiene lugar la interacción, e.g., los objetos, las personas y los eventos que son periféricos a la tarea que se
está desarrollando en un momento dado, pero que pueden tener un impacto en el comportamiento: a) del sistema, e.g., un entorno ruidoso puede eliminar la realimentación por audio,
y/o b) del usuario, e.g., su localización provee un contexto para la relevancia de la información
[Calvary et al., 2004, Calvary et al., 2001].
4.1.2
Contexto de uso de los sistemas cooperativos
El desarrollo de un espacio de interacción cooperativo puede resultar complejo, ya que debe considerar varios aspectos, e.g., las actividades de los colaboradores y la conciencia de grupo. Dourish y Bellotti definen conciencia de grupo como: un conocimiento de las actividades de otros
que provee un contexto para las actividades propias. Algunos investigadores consideran que la
conciencia puede clasificarse en cuatro tipos [Gutwin et al., 1995, Dourish and Bellotti, 1992]:
• conciencia informal: permite conocer tanto la ubicación de los colaboradores como su
estado de disponibilidad;
• conciencia de grupo estructural: proporciona conocimiento de roles, responsabilidades,
posición social o profesional;
• conciencia social: permite el entendimiento tanto del contexto social como del conversacional, y
• conciencia de espacio del trabajo: permite dar información sobre la interacción de los
demás en el espacio compartido.
Considerando las definiciones previas de conciencia de grupo y de contexto de uso, se propone
utilizar la terna siguiente <grupo de colaboradores, conjunto de plataformas, entorno
común> para denotar el contexto de uso de los sistemas cooperativos. La terna propuesta
considera la conciencia de grupo, e.g., durante la asignación de una tarea se debe considerar
el dispositivo de cómputo del colaborador, ya que este puede tener limitaciones que podrı́an
impedir la realización de la actividad.
El elemento grupo de colaboradores denota los arquetipos humanos que usan el sistema
cooperativo para llevar a cabo un proyecto común.
76
El elemento conjunto de plataformas se refiere a las caracterı́sticas de hardware y software
de los dispositivos de cómputo que alojan al sistema cooperativo y que son usados de manera
individual por cada colaborador (e.g., una computadora portátil o un teléfono inteligente) o
de forma compartida por algunos miembros del grupo (e.g., un pizarrón inteligente). Este
elemento también incluye los dispositivos que permiten un mejor funcionamiento del sistema
(e.g., impresoras y servidores).
El elemento entorno común concierne a las condiciones fı́sicas y sociales, e.g., personas,
objetos y eventos, que son externos al grupo de trabajo pero que tienen una influencia tanto
en los miembros del grupo como en el sistema cooperativo. Este elemento también incluye
un entorno virtual (e.g., espacios de trabajo públicos y privados, objetos compartidos). El
desktop se define como un conjunto de aplicaciones disponibles para un colaborador, e.g., un
colaborador puede tener un dominio de aplicación (e.g., editor colaborativo) diferente por cada
rol [Haake et al., 2010]. Los objetos compartidos se refieren al texto, a las imágenes, al audio,
al video que son compartidos por los colaboradores a través de un espacio de trabajo público.
4.2
Relación entre escenarios y aplicaciones
La técnica usada para crear el marco XARE es la de bottom-up, por consiguiente se partió de
un conjunto de escenarios que nos sirvieron para identificar algunas necesidades de los sistemas
cooperativos adaptables a cambios contextuales.
Los cambios contextuales abordados en esta tesis se ponen en evidencia en los siete escenarios
propuestos (cf. Figura 4.1). Algunos de los escenarios hacen referencia a herramientas computacionales para dar una mejor explicación. En la figura 4.1, los rectángulos que representan
a los escenarios tienen diferentes colores: verde oliva, amarillo, verde limón y rosa, con el fin
de denotar el grado de aportación al desarrollo del marco XARE. El color verde oliva indica
que se detectaron suficientes aplicaciones para automatizar el escenario; el color amarillo indica
que las aplicaciones identificadas no han sido implementadas y que no se asegura una automatización completa del escenario; el color verde limón indica que las aplicaciones encontradas no
son suficientes como para automatizar el escenario, y el color rosa indica que hasta el momento
no se han encontrado aplicaciones que puedan automatizar el escenario.
Ası́ como los escenarios están marcados con diferentes colores, los aplicaciones también han
sido representados con diferentes colores: azul, naranja y rojo, para denotar su estado de
avance. El color azul representa a las aplicaciones implementadas; el color verde corresponde
a las aplicaciones en proceso de desarrollo y el color rojo indica que las aplicaciones han sido
identificadas pero no implementadas.
Para una mejor descripción de la Figura 4.1, se explicará primero las aplicaciones identificadas:
1. la barra de colaboradores [Romero et al., 2013] expresa la conciencia de grupo mediante la
Capı́tulo 4
77
Escenario 2:
Remodelación de
componentes de la IU
Desktop
enriquecido
Herramienta de
votación
Editor de mapas
mentales
Escenario 3: Redistribución del sistema
colaborativo en
función de la
configuración
Barra de
colaboradores
Escenario 1:
Mejoramiento del
trabajo colaborativo
Administrador de
contenidos vía NFC
Editor de dibujos
Herramienta de
medios de contacto
y disponibilidad
Escenario 7: Uso de
diferentes modalidades
en la notificación
Escenario 4: Adaptar
los medios de
contacto y
disponibilidad
Aplicación implementada
Escenario 6: Adaptar
la información
Editor de textos
Escenario 5: Ocultar
información (texto,
imágenes, etc.)
Aplicación en proceso de desarrollo
Aplicación identificada pero no implementada
Escenario completo con aplicaciones identificadas e
implementadas
Escenario con algunas aplicaciones identificadas pero
no todas están implementadas
Escenario con ninguna aplicación identificada
Escenario con aplicaciones insuficientes para automatizar
el escenario
Figura 4.1: Escenarios y aplicaciones
foto y el nombre de los colaboradores pertenecientes a un grupo. Dicha barra organiza a los
colaboradores, dependiendo su ubicación fı́sica, como: presentes, virtualmente presentes
y ausentes;
2. la herramienta de votación [Romero et al., 2013] permite a un grupo de colaboradores
participar en una votación electrónica de manera anónima o conocida;
3. el editor de mapas mentales [Romero et al., 2013] faculta la creación de diagramas para
organizar ideas.
Es importante mencionar que la herramienta de votación y el editor de mapas mentales permiten tanto la interacción co-localizada como la distribuida. Ambas aplicaciones
muestran los iconos relacionados al rol del colaborador que está usando la aplicación.
Finalmente, ambas aplicaciones usan la barra de colaboradores para proveer conciencia
78
de grupo.
4. el editor de dibujos tiene como objetivo crear imágenes vectoriales, con la caracterı́stica
de que soporta transiciones del trabajo individual al trabajo colaborativo y viceversa.
Los colaboradores pueden pasar de su respectivo espacio privado a un espacio común
donde pueden interactuar mediante un dispositivo con una pantalla grande (e.g., un
pizarrón electrónico) o un arreglo de tablets. El paso de un espacio de trabajo privado a
uno compartido origina que los iconos se adapten a los colaboradores involucrados en la
interacción, considerando sus roles y sus jerarquı́as;
5. la herramienta de medios de contacto y disponibilidad [?] ofrece de manera visual tanto la
disponibilidad como los medios de contacto disponibles de un colaborador, considerando
varios parámetros, tanto del colaborador a contactar como del que desea contactarlo;
6. la desktop enriquecido [?] permite relacionar los objetos compartidos entre diferentes
aplicaciones para enriquecer el trabajo de los colaboradores involucrados con dicho objeto
compartido;
7. el administrador de contenidos vı́a NFC [Romero et al., 2013] enriquece las reuniones
co-localizadas al proveer información extra en el tiempo y lugar indicado, mediante la
tecnologı́a NFC (Near Field Communication);
8. el editor de textos permite ocultar información restringida ante personas no autorizadas,
quienes están cerca del área de despliegue de la información.
Después de describir las herramientas, se describirán los escenarios representados en la Figura
4.1.
El escenario “Mejoramiento de trabajo colaborativo” pretende enriquecer la colaboración
entre los miembros de un grupo al mantener, en todo momento, el contexto de los objetos
compartidos en el espacio de trabajo y al encontrar algunas relaciones existentes entre los
colaboradores, en función de su interacción con dichos objetos. A partir de las relaciones
encontradas, el sistema colaborativo provee sugerencia pro-activa al lanzar en ejecución otras
aplicaciones para manipular un objeto dado y asociar diferentes conversaciones textuales en
curso que hacen referencia a dicho objeto. La herramienta relacionada con este escenario es el
desktop enriquecido.
El escenario “Remodelación de componentes de la interfaz de usuario” permite la modificación
de componentes mediante las siguientes acciones: ocultar, sustituir o agregar; la modificación
incluye referenciar a otro dispositivo de hardware que proporcione la misma funcionalidad
del componente modificado. Este escenario es importante, ya que sus especializaciones se
representan en los escenarios del tres al seis. Aún cuando existen particularidades en estos
escenarios es importante recalcar que este segundo escenario permite adaptar los ı́conos (e.g.,
en las herramientas de votación, de mapas mentales, editor de dibujos y de medio de contacto
y de disponibilidad) y las aplicaciones (e.g., desktop enriquecido) en función del rol de los
colaboradores.
Capı́tulo 4
79
El escenario “Redistribución del sistema colaborativo en función de la configuración del
grupo” adapta los componentes que son afectados por el trabajo co-localizado y redistribuido.
Algunos de los componentes detectados que son susceptibles a dichas modificaciones corresponden a el espacio compartido y público, la conciencia de grupo y el uso de dispositivos con
pantallas grandes y buena resolución para una mejor interacción (e.g., un pizarrón electrónico).
Las herramientas asociadas a este escenario corresponden a: herramienta de votación, herramienta mapas mentales, herramienta de dibujo y herramienta barra de colaboradores.
El escenario cuatro modifica los componentes relacionados con la disponibilidad y los medios
de contacto dependiendo de algunos parámetros relacionados con los colaboradores. La herramienta relacionada con este escenario es medios de contacto y disponibilidad).
El escenario cinco adapta la información desplegada en un dispositivo, e.g., pizarrón
electrónico o una laptop, al detectar una persona que no pertenece al equipo de trabajo. Al
detectar a dicha persona, la información es cambiada por otra de menos relevancia para que no
pueda ser visualizada por dicha persona. En este escenario, se envı́a una notificación al resto
del grupo de colaboradores acerca de la presencia de alguien ajeno al equipo para que no envı́en
mensajes u otro tipo de información importante en ese momento. La herramienta relacionada
a este escenario corresponde al editor de textos.
El escenario seis permite proveer información que puede ser útil a los colaboradores, considerando el lugar, la fecha y el rol de los colaboradores. Este escenario tiene asociada la
herramienta administrador de contenidos vı́a NFC.
El escenario siete ofrece una gama de posibilidades para notificar a los colaboradores acerca
de un evento en especı́fico considerando la actividad en curso de cada uno de ellos, ası́ como la
importancia de dicho evento. Este escenario hasta al momento no tiene asociada una aplicación
en especı́fico.
4.3
Escenario 1: Mejoramiento del trabajo colaborativo
Este escenario describe un espacio de trabajo capaz de mantener el contexto de los objetos manipulados por un grupo de colaboradores durante una sesión de trabajo, ası́ como de relacionar
diferentes conversaciones referentes a un mismo objeto compartido y de ofrecer funcionalidades
adicionales (e.g., herramientas) para manipularlo, con el fin de mejorar la colaboración entre
los miembros del grupo. Antes de describir el escenario, se presenta una introducción acerca de
las aplicaciones cooperativas adaptativas que son usadas en este escenario, ası́ como los roles y
la granularidad de los objetos compartidos soportados por estas aplicaciones.
80
4.3.1
Preámbulo
Para mantener el contexto de los objetos compartidos producidos durante una sesión de trabajo,
un grupo de colaboradores depende de un desktop enriquecido que provea varias aplicaciones
cooperativas diseñadas para trabajar en conjunto.
El desktop enriquecido es ejecutado por los colaboradores al momento de ingresar a su sesión
para trabajar en las tareas asignadas. En este caso de estudio, el desktop enriquecido permite
la ejecución de tres aplicaciones, las cuales pueden estar relacionadas entre ellas para proveer
más información al contexto de trabajo. Las aplicaciones son las siguientes:
1. un editor colaborativo de documentos HTML que permite la fragmentación para facilitar
la producción concurrente;
2. un pizarrón multi-usuario que permite a los colaboradores llevar a cabo sesiones de lluvia
de ideas y dibujar diagramas con extensión JPG;
3. un servicio de mensajerı́a que soporta la comunicación de forma directa entre los colaboradores.
La granularidad de los objetos compartidos soportada por el editor colaborativo desde una
palabra, una frase, un párrafo o una sección hasta todo el documento. Por otro lado, el pizarrón
multi-usuario tiene diferentes granularidades, las cuales van desde figuras básicas (e.g., lı́neas,
cuadrados, cı́rculos y rectángulos) hasta un diagrama completo. La tercera aplicación soporta
grupos no estratificados, mientras las dos primeras soportan tres roles:
1. el rol de coautor permite a los colaboradores escribir texto y dibujar diagramas;
2. el rol de lector da la posibilidad a los colaboradores de leer texto y de visualizar imágenes;
3. el rol de revisor permite a los colaboradores hacer comentarios respecto a la forma y al
contenido del texto y de los diagramas.
Es importante mencionar que no todas las aplicaciones cooperativas adaptativas contenidas
en el desktop enriquecido están visibles en todo momento, para evitar que el usuario se sature
con aplicaciones posiblemente inútiles. Con el objetivo de proveer a los colaboradores con un
espacio de trabajo apropiado, las herramientas están disponibles dependiendo del rol actual
del colaborador. De este modo, un colaborador con el rol de escritor, solo requiere ejecutar
en su desktop enriquecido tanto el editor colaborativo como el pizarrón multi-usuario. En el
caso de un colaborador con el rol de revisor, él requiere que la mensajerı́a instantánea trabaje
coordinadamente con el editor colaborativo y el pizarrón multi-usuario para hacer comentarios
acerca del texto o los diagramas del documento.
Capı́tulo 4
4.3.2
81
Descripción del escenario
Suponga un grupo compuesto por cuatro miembros, Alice, Isaac, Jenny y Sandy, que está
preparando un reporte técnico de manera distribuida. Aunque los miembros del grupo utilizan
dispositivos heterogéneos, estos tienen buenas caracterı́sticas técnicas (e.g., gran tamaño y alta
definición de pantalla, ası́ como buen poder de procesamiento y capacidades de comunicación).
Dadas las caracterı́sticas de los dispositivos, la adaptabilidad de las aplicaciones colaborativas
no se expresa mediante la remodelación de su interfaz de usuario, sino por las funcionalidades
que dichas aplicaciones proveen para que los miembros del grupo puedan llevar a cabo sus
actividades.
El equipo de trabajo ha dividido el documento en secciones, ası́ que cada miembro está
encargado de escribir una sección, mientras sus colegas son responsables de la revisión. De esta
manera, los colaboradores pueden escribir el documento de manera concurrente. En particular,
Sandy e Isaac han estado trabajando juntos porque sus secciones respectivas están relacionadas.
El mismo caso ocurre con Alice y Jenny, ya que ambas están encargadas de dibujar todas las
figuras del reporte técnico.
Cuando Sandy termina de redactar la primera versión de su sección, le pide a Isaac que
revisen conjuntamente dicha sección, ya que ella tiene algunos problemas para expresar sus
ideas. En consecuencia, ellos deciden entablar una comunicación directa mediante la mensajerı́a
instantánea, mientras el editor colaborativo está encargado de mostrar los párrafos sujetos a
discusión.
Por medio de la funcionalidad deixis que provee la mensajerı́a instantánea, los colaboradores
simplemente seleccionan una palabra clave (e.g., this figure, the next section, this paragraph,
those references o here) y crean las hiperligas entre esa palabra y un objeto compartido del
editor colaborativo (e.g., un tı́tulo, un párrafo, una frase, una palabra, una referencia, una
figura o una sección) al seleccionar el objeto compartido. Gracias a esta funcionalidad, los
colaboradores no necesitan copiar los párrafos referenciados desde el editor colaborativo hacia la
mensajerı́a instantánea cuando se está revisando. De este modo, el párrafo mantiene su contexto
(i.e., párrafo anterior y siguiente, figuras asociadas y referencias) en el editor colaborativo (cf.
Figura 4.2).
Mediante la funcionalidad deixis, Isaac escribe: “. . . in this paragraph, you are using the
concept “view-controller pair” without defining it . . . ”. En la frase previa, las palabras “this
paragraph” tiene una liga de hipertexto que apunta a un párrafo del documento abierto en el
editor colaborativo. Ası́, cuando Sandy da clic en la liga creada por Isaac, el editor colaborativo
automáticamente le muestra el párrafo correspondiente a la mitad de la vista y resaltado con
letra de color (morado, en este caso).
Ası́ como el párrafo en cuestión mantiene su contexto, i.e., referencias bibliográficas, párrafos
alrededor y figuras referenciadas, Sandy puede darse cuenta que los comentarios de Isaac están
a la derecha para que ella pueda fácilmente verificar que el concepto “vista-controlador” no
está definido en párrafos previos de la sección.
82
4.1 MVC-based Design
The design of the plastic collaborative whiteboard is based on the
architectural style Model-View-Controller (MVC) [8]. We prefer it to other
styles (e.g., PAC* [10]) as, from our point of view, the MVC principles (several
views for a model) match better with the plasticity principles (several user
interfaces for an application). Thus, MVC simply?es the application structural
representation before and after applying any plastic adaptation. MVC also
facilitates software reutilization by modeling the application as independent
interrelated components.
The basic MVC architecture consists of a model, which represents the
application data; a controller, which interprets user input; and a view, which
handles output. Like many MVC variants, our plastic collaborative whiteboard
implements view-controller pairs as combined components. More particularly,
as shown in Fig. 1, the MVC tree of our plastic collaborative whiteboard
contains the root node, R, and three child nodes, H1, H2 and H3. At runtime,
the R node view-controller is in charge of: 1) creating an instance of the
application, 2) coordinating its children, and 3) communicating with other
distributed instances of the application.
Hello Isaac
Hi Sandy
As you know, I have some
problems to express some ideas
concerning the MVC model…
What do you think of section 4.1?
I think in this paragraph you are
using the concept “view-controller
pair” without defining it….
You should define this concept
before using it!
Fig. 1. The MVC-Based Architecture of the Plastic Collaborative Whiteboard
The R node model stores information about these tasks (e.g., remote
instance identifiers or active children). The children of the R node are:
Figura 4.2: Uso de las palabras deı́cticas “in this paragraph” (en la forma de una liga de hipertexto) por parte de Isaac en la herramienta de la mensajerı́a instantánea para referirse a un
párrafo en el editor colaborativo
Mientras Sandy e Isaac están produciendo una nueva versión del párrafo, Alice y Jenny
también decidieron usar la mensajerı́a instantánea para hablar acerca de los diagramas que
han creado. La mensajerı́a instantánea muestra que Alice escribió “. . . I’d like to highlight H1
in this diagram” (cf. Figura 4.3). Ası́ como Isaac, Alice ha usado las palabras clave “in this
diagram”, el cual tiene una liga de hipertexto hacia la figura 1 del reporte técnico desplegado
en el editor colaborativo. De este modo, cuando Jenny da clic sobre la liga de hipertexto creada
por Alice, el editor colaborativo muestra el diagrama correspondiente a la mitad de la vista
resaltándolo mediante un borde color azul.
Este diagrama también mantiene su contexto, i.e., sección contenedora, tı́tulo de la figura,
párrafos circundantes. Como no es posible modificar este diagrama desde el editor colaborativo,
el espacio de trabajo compartido provee una funcionalidad a los colaboradores para hacer una
copia de tal diagrama en el pizarrón multi-usuario, donde este puede ser modificado. La copia
mantiene una referencia contextual al diagrama mostrado en el editor colaborativo (en este
Capı́tulo 4
83
Hi Jenny! I’d like to highlight H1 in
this diagram as it’s the key node…
Hello Alice! I agree with you, so
shoulders to the wheel!
Jenny
Alice
Figura 4.3: Uso de las palabras deı́cticas “in this diagram” (en la forma de una liga de hipertexto) por parte de Alice en la herramienta de la mensajerı́a instantánea para referirse a la Fig.
1 del pizarrón multi-usuario
caso, un identificador de objeto interno y la localización del objeto en el documento). Ası́, en
cualquier momento, tal diagrama puede ser modificado en el pizarrón multi-usuario, el cual
permite a los colaboradores remplazar fácilmente la versión anterior en el editor colaborativo
por la nueva versión creada en el pizarrón multi-usuario debido a la referencia contextual.
Como Alice y Jenny deciden modificar tal diagrama, una copia es automáticamente creada
en el pizarrón multi-usuario. En este momento, el espacio de trabajo compartido percibe que
Sandy e Isaac están escribiendo un párrafo que hace referencia a la figura que está siendo
modificada por Alicia y Jenny. En consecuencia, el espacio de trabajo compartido sugiere a
Sandy e Isaac seguir la conversación de Alice y Jenny porque puede ser de interés, ya que ellas
están modificando la figura asociada al párrafo que ellos están redactando. Esta sugerencia es
también hecha a Alice y Jenny. Ası́ que Sandy e Isaac están interesados en seguir la conversación
de Alice y Jenny (cf. Figura 4.4) y viceversa (cf. Figura 4.5), ellas pueden acceder a este por
medio de una nueva pestaña agregada en los mensajeros instantáneos, respectivos.
84
Hello Isaac
Hello Sandy
As you know, I have some
problems to express some ideas
concerning the MVC model…
What do you think of section 4.1?
I think in this paragraph you are
using the concept “view-controller
pair” without defining it….
You should define this concept
before using it!
You’re right!
May I define it after this phrase?
Figura 4.4: Se sugiere a Sandy e Isaac seguir la conversación de Alice y Jenny porque ellas
están modificando la figura referenciada por el párrafo que ellos están modificando
Para adaptar las actividades de los colaboradores, el espacio de trabajo compartido tiene
como objetivo hacer más eficiente el trabajo grupal. Gracias a esta funcionalidad, los cuatro
colaboradores pueden coordinar fácilmente su trabajo al evitar errores, duplicaciones innecesarias, y malos entendidos. Si es necesario, estos colaboradores pueden comunicarse directamente para coordinar sus respectivos trabajos, sin perder el contexto de la producción conjunta
de los objetos compartidos.
Adaptación al contexto de uso de los sistemas cooperativos
En este escenario, la adaptación al contexto de uso se aborda de dos maneras. La primera
permite la adaptación al grupo de colaboradores, ya que considera el rol del colaborador para
desplegar las aplicaciones relacionadas con ese rol. La segunda forma de adaptación considera
al entorno compartido, ya que se hace referencia a un objeto compartido de manera directa
o indirecta, e.g., en el escenario se detecta que Sandy e Isaac están describiendo una figura, la
Capı́tulo 4
85
Hi Jenny! I’d like to highlight H1 in
this diagram as it’s the key node…
Hello Alice! I agree with you, so
shoulders to the wheel!
Fonts for H1 should be in red….
Alice
Jenny
Figura 4.5: Se sugiere a Alice y Jenny seguir la conversación de Sandy e Isaac porque ellos
están reescribiendo el párrafo que refiere a la figura que ellas están modificando
cual está siendo modificada por Jenny y Alice.
4.3.3
Desktop enriquecido
Este desktop enriquecido permite la interacción de tres aplicaciones que son: mensajerı́a instantánea, editor colaborativo de documentos y un pizarrón multi-usuario. Una caracterı́stica
importante del desktop enriquecido es que dentro de una conversación realizada desde la mensajerı́a instantánea, se puede hacer referencia a objetos compartidos desplegados en el editor.
Además, el desktop enriquecido permite identificar cuando dos conversaciones hacen referencia
al mismo objeto compartido.
86
Requerimientos funcionales y no funcionales
Los requerimientos funcionales del desktop enriquecido se muestran a continuación:
• Cada colaborador debe identificarse al ingresar al desktop enriquecido.
• El desktop enriquecido debe reconocer a cada colaborador para adaptar su interfaz de
usuario, i.e., mostrar los ı́conos de acceso rápido a las aplicaciones relacionadas con el rol
asignado.
• Cada colaborador podrá usar la función Deixis perteneciente a la mensajerı́a instantánea
para crear diferentes ligas que referencien diferentes objetos compartidos, los cuales
pueden ser párrafos, palabras, imágenes, etc. Dichos objetos están ubicados en el editor colaborativo.
• El colaborador debe hacer una serie de pasos para crear una referencia deı́ctica, los cuales
incluyen: 1) seleccionar el ı́cono deixis para desplegar la ventana llamada “New Deixis”;
2) seleccionar las palabras que servirán de referencia deı́ctica, e.g., this paragraph dentro
de la ventana abierta 3) seleccionar en el editor colaborativo el objeto compartido al que
se hará referencia deı́ctica, y 4) aceptar para terminar de crear la nueva deixis.
• El colaborador podrá acceder a dicha referencia deı́ctica, solo al seleccionar con el ratón la
palabra. En consecuencia, el desktop enriquecido podrá mostrar en pantalla la referencia
al objeto. En caso de que el objeto referenciado sea un párrafo, este cambiara el color de
la letra a rojo para indicar que se está haciendo referencia a ese párrafo. En caso de que
el objeto haga referencia a una imagen, esta estará enmarcada con un recuadro de color
azul.
• El colaborador podrá hacer una copia de la imagen referenciada, del editor colaborativo,
en el pizarrón multi-usuario para hacer modificaciones sobre dicha imagen. Una vez
terminadas las modificaciones, el objeto será actualizado en el documento de textos,
donde ha sido referenciado.
• El colaborador podrá seguir una conversación sugerida por el desktop enriquecido, una vez
que este último detecte que dos conversaciones hacen referencia a un objeto compartido.
Los requerimientos no funcionales del desktop enriquecido corresponden a:
1. El desktop enriquecido debe mostrar en medio de la vista del editor colaborativo el objeto
compartido al que se está haciendo referencia.
2. El desktop enriquecido debe permitir la creación de varias referencias deı́cticas en una
conversación, ası́ como mantener las ligas a dichos objetos.
Capı́tulo 4
87
3. El colaborador que reciba la deixis, e.g., in this paragraph, desde la mensajerı́a instantánea
verán que esta palabra está en color azul y subrayada.
4. El desktop enriquecido está encargado de abrir el pizarrón multi-usuario cuando los colaboradores deseen crear una copia de una imagen referenciada. Además, los colaboradores
autorizados serán responsables de incluir la copia de la imagen requerida, ası́ como de
permitir que dichos colaboradores autorizados modifiquen y actualicen la imagen.
Interfaces de usuario
El desktop enriquecido proporciona información aumentada de tres maneras: 1) muestra las
aplicaciones relacionadas con los roles asignados; 2) localiza fácilmente textos o figuras creados
en un editor colaborativo desde un mensajero instantáneo (cf. Figuras 4.2 y 4.3), y 3) sugiere
a los colaboradores seguir las conversaciones publicas de sus colegas que están relacionadas con
el trabajo en desarrollo (cf. Figura 4.4 y 4.5).
Las variables contextuales que son consideradas para la adaptación contextual corresponden a: 1) rol del colaborador, 2) la referencia deı́ctica, 3) objetos compartidos en uso y 4)
conversaciones actuales.
Una de las variables contextuales se refiere al rol que puede tener asignado el colaborador.
Cuando el colaborador tiene asignado el rol de coautor, de lector o de revisor, él tendrá
accesible las aplicaciones del editor colaborativo y el pizarrón multi-usuario, con la variante de
que el rol de revisor tendrá acceso a mensajerı́a instantánea.
La variable referencia deı́ctica es realizada por un colaborador desde la mensajerı́a instantánea. Dicho referencia resalta las figuras o el texto sin que estos pierdan su contexto.
La variable objetos compartidos en uso debe contener los objetos que están usando todos los
colaboradores que están interactuando en un momento dado. Dicha variable permite identificar
el grado de relación entre dichos objetos compartidos, para proveer sugerencia pro-activa.
La variable conversaciones actuales registraran las las conversaciones de los colaboradores
en un momento dado. Esta variable permitirá que dichas conversaciones sean visualizadas por
otros colaboradores como resultado de la sugerencia pro-activa.
Proceso de adaptación contextual
En los siguientes párrafos se describen los eventos que provocan adaptaciones contextuales:
1. Un colaborador inicia sesión en el desktop enriquecido. Al momento en que dicho
desktop enriquecido autentifica al colaborador; posteriormente, este solicita a una base de
datos los roles del colaborador para determinar las aplicaciones relacionadas con los roles
obtenidos, con la finalidad de ponerlas accesibles al colaborador, e.g., un revisor requiere
88
acceder al editor colaborativo, a la mensajerı́a instantánea y posiblemente al pizarrón
multi-usuario.
2. Un colaborador crea una referencia deı́ctica. La creación de referencias deı́cticas
es posible cuando los colaboradores están llevando a cabo una conversación por medio
de la mensajerı́a instantánea. Para crear dicha referencia, ellos tiene que seleccionar la
opción deixis en la mensajerı́a ası́ como alguna de las palabras deı́cticas, tales como:
this figure, the next section, this paragraph, those references o here. Como consecuencia,
la mensajerı́a resalta la palabra seleccionada al subrayarla, ası́ como cambia el estilo a
negrita y establece el color azul marino (cf. Figura 4.3).
3. Un colaborador selecciona una referencia deı́ctica desde la herramienta de
mensajerı́a. Posterior a la selección de la referencia deı́ctica, el objeto ligado a dicha
referencia (e.g., una figura o un texto como una palabra, un párrafo o una sección) es
mostrado y resaltado en el editor colaborativo, con la finalidad de que dicho objeto no
pierda su contexto dentro del documento, i.e. conserve su página y ubicación. Dependiendo del tipo de objeto seleccionado, algunas de las siguiente adaptaciones pueden
ocurrir:
(a) el editor colaborativo cambia a la página que contiene la figura a mostrar. La figura
es centrada en el área de trabajo, y está rodeada por un cuadro coloreado. Por otra
parte, el editor permite el acceso a la opción ”Make a copy“;
(b) el editor colaborativo cambia a la página que contiene el texto a mostrar, cuya fuente
presenta un color diferente al resto del documento.
4. El colaborador selecciona la opción ”Make a copy”. Esta opción es activada después
de que una figura fue seleccionada a partir de la referencia deı́ctica. Al seleccionar ”Make
a copy“, el desktop enriquecido muestra a los colaboradores involucrados la figura en el
pizarrón multi-usuario para que puedan modificarla. Internamente, el pizarrón multiusuario crea una referencia (un identificador de objeto y la localización en el documento)
al diagrama mostrado en el editor colaborativo.
5. Actualización de la copia de una figura en el editor colaborativo. El evento de
actualizar una copia es generado por los colaboradores que solicitaron dicha copia, desde
el editor colaborativo. Al momento de solicitar dicha actualización, el pizarrón multiusuario remplaza la figura del editor colaborativo por la figura que tiene el pizarrón.
6. El desktop enriquecido propone seguir una conversación. Este evento sucede cuando
el desktop enriquecido detecta que varios colaboradores hacen referencia a uno objeto
compartido. En consecuencia, el desktop enriquecido, mediante una ventana, propone
a los colaboradores en cuestión seguir la conversación actual que llevan sus colegas por
mensajerı́a instantánea para facilitar su trabajo, ya que todos estos colaboradores hacen
referencia al mismo objeto.
Capı́tulo 4
89
7. Los colaboradores acepta la recomendación de seguir una conversación. Si
los colaboradores seleccionan el botón Ok de la ventana que sugiere seguir otras conversaciones, la mensajerı́a crea una nueva pestaña por cada grupo que hace referencia al
objeto compartido que ellos están usando. En esta nueva pestaña, ellos pueden ver la
conversación en curso de los otros colaboradores (cf. Figura 4.2).
4.4
Escenario 2: Remodelación de componentes de la
interfaz de usuario
El objetivo de esta propuesta es ocultar, sustituir o agregar componentes de los sistemas cooperativos. Dichos componentes pueden ser el espacio compartido o privado, los ı́conos de acceso
de una aplicación, un archivo de texto o de imágenes, parte del contenido de archivos, un ı́cono,
etc.
4.4.1
Preámbulo
En ocasiones los sistemas cubren una amplia gama de funcionalidades, las cuales frecuentemente
se ven reflejadas en componentes de la interfaz de usuario, e.g., menús o ı́conos. La mayorı́a
de las veces los usuarios no utilizan varios componentes por muchas razones. Algunos de los
motivos para ocultar o sustituir los componentes o funcionalidades se mencionan a continuación:
• mostrar solo los iconos relacionados con su actividad, e.g., si un revisor de un artı́culo
utiliza un teléfono inteligente, entonces el sistema cooperativo que está utilizando debe
ocultar el ı́cono de insertar imagen debido al reducido espacio de la pantalla;
• ocultar componentes cuando:
– existan componentes innecesarios dado los roles de un colaborador;
– estos no tengan funcionalidad debido a que el recurso humano o fı́sico asociados no
está disponible, e.g., el ı́cono de una impresora debe ocultarse cuando está descompuesta;
• sustituir la funcionalidad de un dispositivo que no está disponible, e.g., el espacio de
memoria local es insuficiente para almacenar el trabajo actual, ası́ que la funcionalidad
de guardar información localmente puede ser cambiada por guardar información en el
dispositivo de un colaborador conectado al sistema o en algún servidor.
Una vez que el sistema reduzca el número de componentes se puede aplicar alguna forma
de remodelación descrita por Calvary et al. [Calvary et al., 2006] para adaptar la interfaz de
usuario a diferentes situaciones contextuales.
90
La herramienta que permitirá ejemplificar el escenario es un editor de mapas mentales que
permite que los colaboradores puedan asumir los siguientes roles:
• administrador, el cual le permite crear un nuevo mapa mental, elegir a los participantes
y asignarles un rol;
• autor, el cual le da la posibilidad de agregar, modificar, mover o eliminar elementos en el
mapa mental, y
• revisor, el cual le permite agregar, modificar o eliminar comentarios sobre los elementos
del mapa mental.
Además dicha herramienta soporta las siguientes configuraciónes del grupo: 1) co-localizado
(fı́sicamente presente), cuando todo el grupo se encuentra en el mismo lugar de reunión y 2)
distribuido (virtualmente presente), cuando algún usuario se encuentra en un lugar diferente al
de reunión.
Otra caracterı́stica importante de mencionar acerca de la herramienta de mapas mentales se
refiere a la dimensiones de la pantalla de un dispositivo. Dichas dimensiones son clasificadas en:
1) pantalla pequeña, cuando la pantalla del dispositivo es de un tamaño menor a siete pulgadas
y 2) pantalla grande, cuando la pantalla del dispositivo es de siete pulgadas o más.
4.4.2
Descripción
Supongamos que un grupo de colaboradores, compuesto por Coello (Isaac), Fraga (Alicia),
Chakraboborty (Jenny), Morales y Mejia, necesita realizar un mapa mental sobre software
libre. Dichos colaboradores han planeado formalmente una cita que ha sido registrada en la
agenda de la sala de reuniones.
Coello acude a la reunion llevando consigo una laptop, en tanto Alicia asiste cargando un
teléfono inteligente. Cuando Isaac y Alicia entran a la sala de reuniones, son autenticados
automáticamente por medio de una etiqueta NFC que se encuentra en la entrada de la sala.
Mientras tanto, Jenny entra al sistema manualmente introduciendo su nombre de usuario y
contraseña mediante su tablet PC, ya que ella ha decidido interactuar con sus colegas de manera
remota.
Cuando Isaac se aproxima al pizarrón interactivo de la sala de juntas y toca la etiqueta
NFC asociada a dicho pizarrón, se muestra la pantalla principal que contiene las aplicaciones
disponibles y un mensaje que indica que su sesión ha iniciado. Además, se visualiza una barra
de colaboradores donde se muestran los colaboradores virtualmente presentes, en este caso, el
nombre y la foto de Jenny. Desde la pantalla principal, Isaac ejecuta el editor colaborativo
de mapas mentales, el cual le asigna el rol de administrador que le permitirá seleccionar a los
coautores y asignarles sus respectivos roles. Isaac decide dar el rol de revisor a Jenny y el rol de
Capı́tulo 4
91
autor a Alicia. En particular, el rol de autor permite la adición, o eliminación y modificación de
los elementos del mapa mental, mientras que el rol de revisor permite la adición, modificación
y eliminación de los comentarios asociados a dichos elementos. Una vez que Isaac concluyó la
asignación de roles a los coautores, el editor de mapas mentales se ejecuta automáticamente en
los dispositivos móviles de sus colegas.
La interfaz de usuario del editor de mapas mentales se adapta a las dimensiones de la pantalla
del dispositivo, a la configuración del grupo y al rol del usuario (administrador, autor y revisor).
Por lo tanto, en el dispositivos de Alicia, la interfaz de usuario de esta herramienta muestra
una vista radar interactiva [Utwin et al., 1996] donde se presenta unicamente la estructura del
mapa mental. Por el contrario, en el pizarrón interactivo y en la tablet de Jenny, la interfaz de
usuario muestra una vista detallada del mapa mental, ası́ como un barra de colaboradores que
contiene el nombre y la foto de los participantes virtual y fı́sicamente presentes.
A través de la vista radar interactiva mostrada en el dispositivo móvil de Alicia pueden añadir,
modificar, modificar,mover y eliminar elementos, mientras observan una vista detallada del
mapa mental en el pizarrón interactivo. Jenny puede agregar, modificar y eliminar comentarios
desde la vista detallada del mapa mental mostrada en su tablet, i.e., el editor de mapas metales
ofrece solo las funcionalidades dado el rol del colaborador.
Después de que Alicia trabaja un largo rato en el mapa mental, ella decide salvarlo en su
teléfono inteligente con el cual ha estado trabajando en la sesión actual. Cuando ella selecciona
el ı́cono de guardar, este despliega un letrero indicando que su teléfono inteligente no tiene
suficiente espacio para almacenar el diagrama, ası́ que el editor de mapas mentales propone
utilizar el disco duro de la computadora de Isaac o el de un servidor. Es importante mencionar
que el editor no ofrece el disco duro de Jenny porque ella esta fuera de lı́nea.
La adaptación de este escenario al contexto de uso de los sistemas cooperativos comprende dos
de las tres dimensiones propuestas: grupo de colaboradores y conjunto de plataformas.
La adaptación al grupo de colaboradores se logra ya que a a partir del rol del colaborador,
el editor de mapas mentales decide ocultar los iconos no utilizados. En el caso de Jenny, el editor
de mapas mentales solo ofrece las funcionalidades que permiten manipular (agregar, modificar
y eliminar) comentarios. Por otra parte, el sistema considera el conjunto de plataformas
de dos maneras: 1) el mapa mental es mostrado mediante una vista radar interactiva o una
detallada dependiendo del dispositivo, y 2) la funcionalidad ”guardar localmente” es sustituida
por guardar en otro dispositivo, e.g., el que está usando Isaac o en un servidor.
92
4.4.3
Editor de mapas mentales
La aplicación de edición colaborativa de mapas mentales permite a un grupo de colaboradores
trabajar en un documento común de manera simultánea. Por lo tanto, los cambios realizados
por un colaborador al documento actual son percibidos de manera inmediata por los demás
participantes. Los colaboradores pueden interactuar con el mapa mental, ya sea a través de
algún pizarrón interactivo ubicado dentro del lugar de reunión o por medio de sus dispositivos
móviles.
Los requerimientos funcionales del editor de mapas mentales se presentan a continuación:
1. Identificar al administrador del mapa mental.
2. Permitir que el administrador pueda crear un nuevo mapa mental, seleccionar a los participantes y asignar un rol a cada uno.
3. Adaptar su interfaz de usuario de acuerdo al rol del usuario, a las dimensiones de la
pantalla de su dispositivo y a la configuración del grupo, i.e., si se encuentra trabajando
co-localizadamente o de manera remota.
4. Permitir agregar, modificar o eliminar elementos o comentarios desde una vista detallada
mostrada en un pizarrón interactivo o una tableta.
5. Permitir agregar, modificar o eliminar elementos o comentarios desde una vista radar
interactiva mostrada en un dispositivo móvil.
6. Mostrar una barra de desplazamiento horizontal y una vertical cuando las dimensiones
del mapa mental sobrepasen a las del pizarrón interactivo.
7. Permitir exportar el mapa mental a una imagen en formato png.
Los requerimientos no funcionales del mapa mental son los siguientes:
1. Permitir que dos o más usuarios puedan agregar elementos al mapa mental simultáneamente.
2. Maximizar la eficiencia mediante la navegación con un lápiz (en caso de utilizar un
pizarrón interactivo) o una pantalla táctil (en caso de utilizar dispositivos móviles).
3. Tanto en el pizarrón interactivo como en una tableta, se deben distinguir claramente los
detalles del mapa mental a una distancia considerable.
4. Reflejar inmediatamente, en todos los dispositivos, las modificaciones hechas por un
usuario sobre el área de dibujo del mapa mental.
Capı́tulo 4
93
Interfaz de usuario
Para llevar a cabo la adaptación al contexto, la aplicación considera las siguientes variables:
1) el rol del colaborador, 2) la configuración del grupo y 3) las dimensiones de la pantalla del
despliegue.
Los roles que puede asumir un usuario son: 1) administrador, 2) autor y 3) revisor. Escribir
que pasa en cada caso.
La configuración del grupo puede ser: 1) co-localizado (fı́sicamente presente), cuando todo
el grupo se encuentra en el mismo lugar de reunión y 2) distribuido (virtualmente presente),
cuando algún usuario se encuentra en un lugar diferente al de reunión. La dimensiones de
la pantalla de un dispositivo son clasificadas en: 1) pantalla pequeña, cuando la pantalla del
dispositivo es de un tamaño menor a siete pulgadas y 2) pantalla grande, cuando la pantalla
del dispositivo es de siete pulgadas o más.
La herramienta editor cooperativo de mapas mentales cambia su interfaz de usuario dependiendo del rol del colaborador, e.g., revisor o autor. Tanto los roles como el nombre del mapa
son asignados por un colaborador mediante una ventana (cf. Figura 4.6).
Figura 4.6: Elección de participantes y sus roles en la creación del mapa mental
Después de haber asignados los roles, cada colaborador recibirá una notificación para participar en el desarrollo de dicho mapa mental. La IU para los colaboradores con rol de revisor
94
podrán ver el mapa mental y agregar en cada nodo un comentario (cf. Figura 4.7), por tal
razón pueden ver los iconos que permiten agregar, eliminar o modificar un comentario.
Figura 4.7: Vista del mapa mental cuando el colaborador asume el rol de revisor
La IU para los colaboradores autores contiene los iconos necesarios para agrega un nodo,
editarlo o eliminarlo, pero no podrán hacer comentarios. Dicha interfaz también les muestra
una vista del mapa mental (cf. Figura 4.8).
Esta herramienta también cambia la IU dependiendo del trabajo co-localizado o distribuido,
ası́ como las caracterı́sticas de la pantalla. En el caso de los colaboradores co-localizados podrán
tener dos IU de usuario dependiendo del tamaño de la pantalla. Pantallas para teléfonos
inteligentes pulgadas se muestra sin detalles el mapa mental (cf. Figura 4.9a); en cambio,
dispositivos como tablets tendrán aun vista detallada del mapa mental (cf. Figura 4.9b).
Finalmente, los colaboradores distribuidos deben tener una pantalla de 8 pulgadas o mas, ya
que ellos requieren a detalle el mapa conceptual, ası́ como la barra de colaboradores (cf. Figura
4.10).
La adaptación al contexto, en esta herramienta considera las siguientes variables contextuales:
1) el rol del colaborador, 2) la configuración de grupo y 3) las dimensiones de la pantalla del
despliegue. Los roles que puede asumir un usuario son: 1) administrador, el cual permite crear
un nuevo mapa mental, elegir a los participantes y asignar un rol a cada uno de ellos, 2) autor,
el cual permite a un colaborador agregar, modificar, mover o eliminar elementos en el mapa
Capı́tulo 4
95
Figura 4.8: Vista del mapa mental cuando el colaborador asume el rol de autor
mental y 3) revisor, el cual permite a un colaborador agregar, modificar o eliminar comentarios
en el mapa mental. La configuración de grupo puede ser: 1) co-localizado (fı́sicamente presente),
cuando todo el grupo usuario se encuentra en el lugar de reunión y 2) distribuido (virtualmente
presente), cuando algún usuario se encuentra en un lugar diferente al lugar donde se lleva
a cabo la reunión. La dimensiones de la pantalla de un dispositivo son clasificadas en: 1)
pantalla pequeña, cuando la pantalla del dispositivo es de un tamaño menor a siete pulgadas y
2) pantalla grande, cuando la pantalla del dispositivo es de siete pulgadas o más.
Proceso de desarrollo de mapas mentales
A continuaciónse describe con mayor detalle el proceso que se lleva a cabo para crear un mapa
mental. Se asume que un grupo de colaboradores se reúne en una sala de juntas que cuenta con
un pizarrón interactivo. Durante el proceso de edicióncolaborativa, la aplicación pasa a través
de tres fases principales:
• Inicialización de un nuevo mapa mental: cuando el organizador de la reunión pasa
a la zona donde se encuentra el pizarrón interactivo, su presencia es detectada al acercar
su dispositivo móvil a la etiqueta NFC asociada a dicho pizarrón y, como resultado de
esta acción , su sesión es iniciada automáticamente. Desde el pizarrón interactivo, el
colaborador selecciona el editor colaborativo de mapas mentales, el cual le otorga el rol
de administrador. En consecuencia, la aplicación muestra una pantalla donde se enlis-
96
(a) Vista radar interactiva en los dispositivos móviles de
los colaboradores colocalizados
(b) Vista detallada en los dispositivos móviles de los colaboradores colocalizados
Figura 4.9: Adaptabilidad de la interfaz de usuario del editor de mapas mentales con base en
la configuración de grupo y las dimensiones de la pantalla de despliegue
tan los colaboradores tanto fı́sicamente presentes como virtualmente presentes. Desde
dicha pantalla el administrador puede seleccionar a los colaboradores participantes en la
creación del mapa mental y asignar el rol que asumirá cada uno (ver Figura ??). Al terminar tal proceso, la aplicación envı́a una notificación de participación a los dispositivos
de los colaboradores elegidos por el administrador. Además, la aplicación presenta en el
despliegue compartido la vista inicial del mapa mental, la cual muestra únicamente el
nodo raı́z desde donde se podrán agregar más elementos.
• Edición del mapa mental: una vez que los colaboradores seleccionaron la notificación de participación en la creación de un mapa mental, la aplicación se ejecuta automáticamente y muestra una interfaz de usuario adaptada de acuerdo al contexto de uso
del usuario (ver Figura ??). Con base en el rol del usuario (autor o revisor ), la interfaz
de usuario muestra las acciones disponibles y oculta las acciones restringidas para ese rol.
Además, en función de la configuración del grupo y de las dimensiones de la pantalla del
dispositivo, se muestra ya sea una vista radar interactiva o una vista detallada del mapa
mental.
• Finalización y exportación del mapa mental: después de que los colaboradores, en
Capı́tulo 4
97
Figura 4.10: Vista detallada en los dispositivos móviles de los colaboradores distribuidos
común acuerdo, han decidido que el mapa mental está concluido, el administrador puede
exportar dicho mapa a una imagen en formato png para su impresión o reproducción.
Con el fin de mostrar la manera en que el editor colaborativo de mapas mentales se adapta a
los cambios contextuales, se describe una lista de eventos que provocan la adaptación de dicho
editor:
1. un administrador selecciona a los colaboradores participantes, asigna el rol de cada uno y
crea el nuevo mapa mental: cuando el administrador inicia un nuevo mapa mental se envı́a
una notificación a los dispositivos móviles de los participantes presentes y virtualmente
presentes, donde se solicita su participación;
2. un colaborador con rol de revisor selecciona la notificación de participación en la creación
del mapa mental: se ejecuta el editor colaborativo de mapas mentales en su dispositivo y
la interfaz de usuario de dicho editor se adapta de tal manera que despliega únicamente
las opciones disponibles para el rol del colaborador (autor o revisor ). A continuación se
presentan las opciones disponibles para cada colaborador de acuerdo a su rol:
• autor: permite agregar, editar, mover y eliminar elementos en el mapa mental;
• revisor: permite agregar, editar o eliminar comentarios en el mapa mental;
98
De igual manera, la interfaz de usuario se adapta de acuerdo a la combinación de las siguientes variables contextuales: a) configuración de grupo y b) dimensiones de la pantalla
de despliegue. La IU se adapta de tres maneras, dos de ellas ocurre en una interacción
cara a cara con dispositivos pequeños (vista radar interactiva) y con dispositivos grandes
(vista detallada). En el caso de los colaboradores distribuidos, ellos sólo podrán usar
dispositivos como tablets para tener una vista detallada y la barra de colaboradores (cf.
Figura 4.10). La vista radar interactiva muestra la estructura del mapa mental, ya que
las dimensiones de la pantalla del dispositivo no permiten una buena visibilidad de los detalles del mismos . Tanto para los colaboradores co-localizados como para los distribuidos
con dispositivos con pantalla grande, la vista detallada muestra toda la información del
mapa mental, i.e., la etiqueta de cada nodo y la etiqueta de las conexiones entre nodos,
si existen. Para los participantes distribuidos, se muestra adicionalmente una barra que
muestra los colaboradores fı́sicamente presentes, virtualmente presentes y ausentes en el
lugar de reunión (ver Figura 4.10).
En el caso del pizarrón interactivo, también se presenta una vista donde se puede observar
con detalle el mapa mental y una barra que muestra únicamente a los colaboradores
ausentes y virtualmente presentes.
3. Un colaborador agrega, modifica o elimina elementos o comentarios: los cambios realizados por el colaborador, ya sea autor o revisor, se ven reflejados en los dispositivos de
todos los colaboradores y en el pizarrón interactivo;
4. El mapa mental sobrepasa las dimensiones del pizarrón interactivo: la vista del mapa
mental muestra una barra de desplazamiento horizontal y una vertical, tanto en el pizarrón
interactivo como en los dispositivos móviles.
Proceso de adaptación contextual
4.5
Escenario 3: Redistribución del sistema colaborativo
en función de la configuración del grupo
Este escenario pretende proveer funcionalidades necesarias cuando los colaboradores están trabajando co-localizadamente (cara a cara) o distribuidamente.
4.5.1
Preámbulo
Los grupos de colaboradores no siempre trabajan de manera co-localizada o distribuida, en
algunas ocasiones trabajan de manera hı́brida, i.e., algunos de manera co-localizada y otros de
manera distribuida en una misma sesión colaborativa. Algunos de los componentes a modificar
son los siguientes:
Capı́tulo 4
99
• la barra de colaboradores puede sufrir algunos de estos cambios;
1. eliminar la foto y el nombre de los colaboradores que integran en ese momento el
grupo co-localizado, ya que dichos integrantes están conscientes de los participantes
presentes;
2. informar a los colaboradores que trabajan de manera distribuida acerca de los miembros del grupo que están trabajando tanto de manera co-localizada como de manera
distribuida;
• el espacio públicode trabajo compartido en una sesión co-localizada podrı́a ser desplegado
en dispositivo con una pantalla de despliegue lo suficientemente grande para que la información sea visible a todos los integrantes. Por otra parte, el espacio de trabajo privado
podrı́a ser mostrado en los dispositivos personales de cada integrante;
• la barra de herramientas de un sistema colaborativo en una sesión co-localizada podrı́a
mostrar los ı́conos relacionados con los roles de los integrantes de dicha sesión.
4.5.2
Planteamiento del escenario 3
Supongamos un grupo de colaboradores formado por Sandy, Alice, Isaac y Jenny trabajan en
la redacción de un reporte técnico de un producto nuevo de software. Sandy e Isaac tienen el
rol de autor, cuya actividad es hacer los diagramas de clases; mientras, Jenny tiene el rol de
revisora, cuya actividad es revisar todo el documento. Alice tiene dos roles: autor y revisor.
Todos los miembros del equipo se encuentran trabajando de manera remota en la parte
del documento asignado. Sandy y Alice crean una cita en una agenda cooperativa con la
finalidad de aclarar ciertas dudas con respecto a los diagramas. El lugar elegido para llevar a
cabo la reunión es una sala de juntas que tiene un pizarrón electrónico. Una vez reunidas las
colaboradoras ingresan al espacio de trabajo desde sus iPad’s. Ambas abren los diagramas de
clases en la aplicación pizarrón multi-usuario.
Alice puede abrir los diagramas con ciertas restricciones debido a su rol. En consecuencia, el
sistema solo ofrece los iconos relacionados, e.g., agregar notas y guardar. En el caso de Sandy,
ella tiene acceso a varios iconos que Alice no, e.g., agregar clases, agregar relaciones y modificar
diagramas. Sandy cuenta con más iconos que Alice debido a su rol.
Después de que ellas ingresan a la herramienta pizarrón multi-usuario, el sistema detecta
que ambas trabajan en el mismo lugar fı́sico (co-localizadamante) y que además ambas están
trabajando sobre las mismas imágenes. Por lo tanto, el sistema realiza las siguientes tareas de
forma simultánea: 1) informa a Isaac y a Jenny que Alice y Sandy están colaborando juntas y
2) propone adaptar la interfaz de Sandy y Alice.
La tarea de informar, a Isaac y a Jenny, que Alice y Sandy están colaborando juntas involucra
modificar la barra de conciencia de todo el grupo de la siguiente forma:
100
• Jenny e Isaac visualizan que las fotos de Alice y Sandy están ubicadas al mismo nivel
y están encerradas con un recuadro. Esta acción le causa extrañeza a Jenny, ası́ que
ella coloca su cursor sobre la foto de Sandy, como consecuencia el sistema le notifica que
ambas están trabajando co-localizadamente;
• Alice y Sandy solo ven las fotos de Isaac y Jenny en su barra de colaboradores, ya que el
sistema deduce que ellas no requieren ver sus fotos puesto están colaborando en el mismo
lugar.
La tarea de adaptar la interfaz de Alice y Sandy sigue esta secuencia de pasos:
1. al detectar que ambas colaboradoras trabajan cara a cara, el sistema propone a ambas
utilizar el pizarrón electrónico para mostrar el espacio público y dejar en sus dispositivos
personales el espacio privado. Ambas colaboradoras aceptan usar el pizarrón electrónico
para desplegar el espacio público, ya que se les facilita tener en una sola vista los diagramas
a discutir;
2. el sistema tiene que decidir que funcionalidades de la aplicación mostrar ya que ambas
colaboradoras tienen diferentes privilegios sobre los diagramas de clases, e.g., Alice solo
puede hacer comentarios sobre dichos diagramas debido a que tiene el rol de revisora,
en cambio Sandy puede modificar dichos diagramas. El sistema puede resolver de varias
maneras el problema anterior, las cuales son:
• combinar las funcionalidades de ambos roles, i.e., unir los ı́conos que tienen acceso
cada una, sin duplicar ı́conos;
• mostrar en el pizarrón electrónico las funcionalidades que coinciden, dejando en sus
dispositivos personales los ı́conos que quedaron fuera de la intersección de sus roles;
• en caso de que el sistema no pueda tomar una decisión, este debe proponer a las
colaboradoras las opciones por medio de una meta-IU para que ellas elijan la más
adecuada
Las colaboradoras dejan que el sistema determine las funcionalidades apropiadas. En este
caso, el sistema combina las funcionalidades de ambos roles, ya que es una opción elegida frecuentemente. Una vez que aparecen dichas funcionalidades sobre el pizarrón electrónico, el
sistema muestra el espacio público sobre este mismo dispositivo. En dicho espacio se muestran
los diagramas que ambas habı́an abierto en sus respectivos dispositivos, excepto algunos diagramas de clases que Sandy habı́a realizado. Los diagramas no son mostrados porque no son
comunes entre ambas colaboradoras.
Cada colaboradora tiene en sus iPad’s su espacio privado, que puede ser solo visto por ellas.
Ellas pueden arrastrar diagramas hacia el borde superior de sus iPad’s, lo cual es interpretado
por el sistema como una instrucción de pasar el diagrama seleccionado desde su iPad hacia el
pizarrón electrónico, que contiene el espacio común
Capı́tulo 4
101
Adaptación del contexto de uso de los sistemas cooperativos
Este escenario se adapta al grupo de colaboradores, al conjunto de plataformas y al
entorno común.
La adaptación al grupo de colaboradores se logra cuando se muestran los ı́conos relacionados al rol de los colaboradores co-localizados, Alice y de Sandy.
La adaptación al conjunto de plataformas ocurrió cuando el sistema sugiere usar el
pizarrón electrónico al detectar que existe un grupo de colaboradores trabajando cara a cara,
ya que el lugar de trabajo tiene instalado dicho pizarrón.
La adaptación al entorno común se logra cuando se asigna el espacio público en el pizarrón
electrónico y el espacio privado en sus dispositivos personales. Otra forma de adaptarse este
escenario a esta dimensión ocurre cuando muestra quienes trabajan de manera co-localizada o
de manera distribuida en la barra de conciencia.
4.6
Escenario 4: Adaptar los medios de contacto y de
disponibilidad
El objetivo de esta propuesta es modificar el medio de contacto y de disponibilidad de dos
colaboradores dependiendo de las actividades, preferencias y el dispositivo en uso.
4.6.1
Preámbulo
Los sistemas cooperativos permiten diferentes formas de comunicación, e.g., mensajerı́a instantánea y correo electrónico, entre los colaboradores. Dichos sistemas no permiten que de
manera automática varı́en los medios de comunicación dependiendo de la actividad, del dispositivo o de la aplicación, ya que estos son cambiados rápidamente dependiendo de las necesidades
de los colaboradores.
De igual manera podrı́a establecerse de manera automática el estado de disponibilidad de los
colaboradores al considerar su actividad. Sin dejar de lado la opción de que los colaboradores
puedan establecer manualmente dicha disponibilidad o el medio de contacto.
4.6.2
Planteamiento del escenario
Un grupo de colaboradores, cuyos nombres corresponden a Isaac, Alicia y Jenny, se encuentra
trabajando a distancia en la redacción de un reporte técnico para un nuevo producto de software. En particular, Isaac y Sandy tienen que redactar la sección de desarrollo, aunque Isaac
102
también es responsable de escribir la sección de introducción. Finalmente, Alice y Sandy están
respectivamente encargadas de escribir y revisar la sección de conclusiones, pero Alice tiene
asignado revisar la sección de introducción y de desarrollo.
Isaac, ingresa al espacio de trabajo, para terminar algunas subsecciones de la sección de
desarrollo, ya que la fecha lı́mite de esta actividad está relativamente cercana. Ası́, basado
en las preferencias de Isaac, el espacio de trabajo determina su disponibilidad (cf. Mecanismo
disponibilidad 5.2.2) como sigue:
1. Ocupado para los colegas: a) cuya actual actividad es muy poco similar o no similar a la
suya, aún si una de sus potenciales actividades es más o menos similar o poco similar a
su actividad actual, y b) cuya actividad actual o potencial son muy poco o no similares
a su actual actividad.
2. Alcanzable si es posible para los colegas: a) cuya actividad es más o menos o poco similar
a la suya, y b) cuya actividad actual es muy poco o no es similar a la suya, pero una de
sus potenciales actividades es similar o muy similar a su actual actividad.
3. Accesible para los colegas, cuya actividad es similar o muy similar a la suya.
Entonces, Isaac define sus propios medios de contacto basados en sus sub-estados de disponibilidad (el primer parámetro de entrada):
1. Cuando él esta ocupado, él puede ser contactado por correo electrónico, ası́ que temas no
relacionados a su actividad actual serán tratados cuando él pueda/quiera.
2. En el caso de estar accesible si es posible, él podrá ser contactado solo por mensajerı́a
instantánea, para ser informado inmediatamente de algún tema y retrasar su respuesta
en caso de ser necesario.
3. Cuando él este accesible, él podrá ser contactado por video-conferencia, voz o mensajerı́a
instantánea porque, desde su punto de vista, los medios de comunicación directa en tiempo
real hacen entendible las ideas y sugerencias relacionadas con su actividad actual.
Cuando Alice y Sandy ingresan al espacio compartido, ellas prefieren que este infiera su
disponibilidad y sus medios de contacto. Tanto Alice como Sandy deciden trabajar en la
sección de conclusiones, ellas colocan su cursor en dicha sección, para empezar a escribir y
redactar respectivamente. Dado que la fecha lı́mite de esa actividad es relativamente distante,
el espacio de trabajo determina los siguientes sub-estado de su disponibilidad:
1. Ocupadas para colegas, cuya actual y potencial actividades sean poco o no similares a sus
actuales actividades.
Capı́tulo 4
103
2. Alcanzables si es posible para colegas, cuya actual actividad es muy similar o no similar
a las suyas, pero una de sus potenciales actividades es muy similar, similar, más o menos
similar o poco similar a su actual actividad.
3. Accesible para colegas, cuya actual actividad es muy similar, similar, más o menos similar,
o poco similar a ellas.
Además, el espacio de trabajo establece el medio de contacto de Sandy basado en la similaridad entre sus actividades y las actividades de sus colegas, considerando las preferencias de
Sandy. De esta manera, ella puede ser contactada a través de:
1. Anotaciones privadas en el texto o correo electrónico por colegas, cuya actividad actual
o potencial son muy similares o similar a su actual o potencial actividad. En este caso,
Sandy ha seleccionado esos medios de contacto, ya que estos aseguran la persistencia de
datos.
2. Sus medios de contacto preferidos, mensajerı́a instantánea o voz, de otra manera.
El espacio de trabajo de Alice también determina sus medios de contacto basado en la
proximidad lógica entre ella y sus colegas dentro del espacio. Ası́, ella puede ser contactada a
través de:
1. Anotaciones privadas en el texto por colegas que están trabajando en el mismo objeto
compartido que esta siendo accedido por ella.
2. Video-conferencia, voz y mensajerı́a instantánea de otra manera.
En todos los casos, la disponibilidad de los medios de contacto dependen del hardware y
software de los dispositivos de Isaac, Sandy y Alice.
Imaginemos que Sandy está revisando la sección de conclusiones y detiene su actividad,
para contactar a Isaac. Ella coloca su cursor en la foto de Isaac (localizado en la barra de
conciencia) y como resultado, un widget desplegable aparece para mostrar: la disponibilidad
de Isaac y los medios de contacto para comunicarse con él. Sandy nota que la disponibilidad
de Isaac es alcanzable si es posible, ya que la fecha lı́mite de la actividad es cercana, aún
cuando las actividades no son similares. Ella es también responsable de escribir la sección de
desarrollo; por consiguiente, los medios de contacto de Sandy para comunicarse con Isaac es la
mensajerı́a instantánea. Sin embargo, ella decide terminar de revisar un párrafo de la sección de
conclusiones, antes de contactarlo. La vista de Sandy también muestra su disponibilidad como
accesible, aunque sus actuales actividades son poco similares, la fecha lı́mite de la actividad de
Alice es distante. El medio de contacto que tiene Sandy para comunicarse con Alice es mediante
anotaciones privadas sobre el texto, porque ambas están trabajando sobre la misma sección.
Isaac percibe que la disponibilidad de Sandy es ocupado, ya que la fecha lı́mite de la actividad
de ella es distante, sus actuales actividades no son similares, y la actividad potencial de él (i.e.,
104
escribir la sección de introducción) tampoco es similar a la actividad actual de ella. Los medios
de contacto de Sandy son las anotaciones privadas sobre el texto y el correo electrónico, porque
la potencial actividad de ella (i.e, escribir la sección de desarrollo) es muy similar a la actual
actividad de Isaac. La vista de Isaac muestra que Alice es accesible, ya que la fecha lı́mite
de la actividad de ella es distante, y sus actuales actividades son mas o menos similares. Los
medios de contacto disponibles para que Isaac contacte a Alice son video-conferencia, voz, y
mensajerı́a instantánea, porque ellos están trabajando en diferentes secciones.
Igual que Sandy, Alice puede ver que la disponibilidad de Isaac es alcanzable si es posible,
ya que la fecha lı́mite de la actividad de él es cercana, y sus actuales actividades son mas o
menos similares. Por lo tanto, los medios de contacto disponibles para que Alice establezca
comunicación con Isaac corresponden a la mensajerı́a instantánea. Distinto a la vista de Isaac,
la vista de Alice muestra que Sandy es accesible, aunque sus actuales actividades son poco
similares, la fecha lı́mite de la actividad de Sandy es distante. Los medios de comunicación
disponibles para que Alice contacte a Sandy son la mensajerı́a instantánea y voz, porque sus
actividades actuales y potenciales son mas o menos similares.
Después, Alice deja la sección de conclusiones, para trabajar en la sección de desarrollo. Ası́
ella pone su cursor en esta última sección y empieza a leer lo que escribió Isaac. Cuando el
espacio compartido detecta esta acción, no solo los sub-estados de la disponibilidad cambian.
Para llegar a un acuerdo acerca de la estructura de la sección, Sandy pone su cursor en la foto
de Isaac otra vez y observa que su estado de disponibilidad es accesible. Ella también nota que
tiene adicionales medios de contacto para comunicarse. De hecho, la instancia del espacio de
trabajo alojado en el dispositivo de Sandy provee esos medios de contacto adicionales, porque
este ha detectado que Sandy e Isaac están compartiendo la misma actividad.
De esta manera, los medios de contacto disponibles para que Sandy establezca una comunicación con Isaac son voz y la mensajerı́a instantánea, aun cuando Isaac también estableció
la herramienta de video conferencia como uno de sus medios de contacto preferidos y su dispositivo es capaz de soportarlo, el dispositivo de Sandy no tiene cámara. En consecuencia una
sesión de video conferencia no puede llevarse a acabo. En la vista de Sandy, Alice permanece
accesible, ya que la fecha lı́mite de la actividad de Alice es distante, y sus actuales actividades
son mas o menos similares. Sin embargo, Los medios de contacto de Alice han cambiado a
mensajerı́a instantánea y voz, porque ellas están trabajando en diferentes secciones. Es importante mencionar que la herramienta de video-conferencia ha sido seleccionada por Alice, pero
no esta disponible para Sandy, como se menciono previamente, el dispositivo de Sandy no tiene
cámara.
En la vista de Isaac, Sandy está accesible, ya que sus actuales actividades son similares.
Por este motivo, los medios de comunicación disponibles para que Isaac contacte a Sandy
permanecen sin cambios. La disponibilidad y los medios de contacto de Alice son las mismas.
Por otro lado, la vista de Alice, el medio de contacto y la disponibilidad de Isaac permanecen
sin cambios, pero Sandy cambia a alcanzable si es posible, las actividades actuales de Alice
y Sandy son mas o menos similar, y la fecha lı́mite de la actividad de Sandy es cercana. Es
Capı́tulo 4
105
importante mencionar que los medios de contacto de Sandy no cambiaron, porque su actual y
potencial actividad son más o menos similar.
Adaptación del contexto de uso de los sistemas cooperativos
Este escenario aborda dos dimensiones del contexto de uso de los sistemas cooperativos. Dichas
dimensiones corresponden a: grupo de colaboradores y conjunto de plataformas.
La adaptación al grupo de colaboradores ocurre cuando cambia la disponibilidad o los
medios de contacto disponibles dependiendo de la actividad actual o potencial de los colaboradores.
La adaptación al conjunto de plataformas se logra cuando se concideran los dispositivos
necesarios para proveer el servicio de un medio de contacto. En el caso de Isaac, él si contaba
con una cámara Web para hacer la vide-conferencia, pero Sandy no tenia alguna, por tal motivo
el sistema no ofreció dicho servicio.
4.6.3
Herramienta disponibilidad y medios de contacto
Esta herramienta tiene como finalidad adaptar la disponibilidad y los medios de contacto dependiendo del colaborador a contactar (colaborador observado) y del que desea contactar a un
colaborador en especı́fico (colaborador observador). Tanto la disponibilidad como el medio de
contacto puede ser calculado de manera automática, dependiendo de las actividades, roles y la
disponibilidad de los colaboradores involucrados, o de manera manual por parte del colaborador.
Los requerimientos funcionales de la herramienta de disponibilidad y medios de contacto se
muestran a continuación:
1. Un colaborador se identifica ante el sistema herramienta de disponibilidad y medios de
contacto.
2. Un colaborador establece manualmente su disponibilidad desde la ventana de configuración de disponibilidad. El colaborador puede configurar cada estado de disponibilidad,
los cuales corresponden a: ocupado, alcanzable si es posible y accesible. Para configurar
cada estado, el colaborador selecciona una o mas de las similitudes entre las actividades
actuales y potenciales del colaborador observador y el observado. Las actividades pueden
ser muy similar, similar, más o menos similar, poco similar, muy poco similar o no similar.
3. Un colaborador permite que el sistema establezca automática su disponibilidad sin necesidad de ingresar a alguna opción ya que esta por omisión dicha opción. En este caso el
106
sistema debe recurrir al conjunto de reglas fijas que incluyan la similaridad de las actividades potenciales y actuales del colaborador observado y observador.
4. Un colaborador establece su medio de contacto de manera manual mediante la ventana de
configuración de los medios de contacto. Los medios de contacto corresponden a: videoconferencia, correo electrónico, audio, mensajerı́a instantánea y anotaciones privadas.
Cada medio de contacto será relacionado con un estado de disponibilidad, ası́ que cuando
se calcule la disponibilidad, los medios de contacto relacionados estarán disponibles para
el colaborador observado.
5. Un colaborador permite que el sistema establezca su medio de contacto de manera automática. El sistema establece dichos medios al recurrir a las reglas establecidas por los
desarrolladores.
6. El colaborador observador solicita la disponibilidad y el medio de contacto del colaborador
observado al colocar el cursor sobre la foto del observado.
7. Un colaborador selecciona un medio de contacto al dar clic sobre las opciones desplegadas.
Los requerimientos no funcionales de la herramienta disponibilidad y medios de contacto se
muestran a continuación:
1. Para mostrar los medios de contacto disponibles entre dos colaboradores, se debe verificar
que ambos tengan el hardware como el software necesario para dicho medio de contacto;
2. El tiempo de verificar el hardware y software necesario para mostrar un medio de contacto
debe ser muy breve, escasos segundos;
3. El tiempo para calcular la disponibilidad no debe ser grande, escasos segundos;
4. Informar al colaborador porque no puede llevar a cabo un medio de contacto.
La principal caracterı́stica de la herramienta disponibilidad y medios de contacto es adaptar
tanto la disponibilidad y el medio de contacto al contexto de dos colaboradores, los cuales
corresponden al colaborador observado y observador. Dicha adaptación se ve reflejada en la
barra de colaboradores (cf. Figuras 4.11 y 4.12).
En la figura 4.11 se muestra la vista de tres colaboradores que ingresan al sistema. Dichas
vistas son diferentes entre cada uno, ya que cada uno hace diferentes actividades (cf. Escenario
4.6 para mas detalle).
En la figura 4.12, la disponibilidad y los medios de contacto han cambiado por el simple
hecho de que Sandy ha cambiado de actividad, sin que los demás colaboradores cambien de
actividad.
Capı́tulo 4
107
(a) Sandy’s view
(b) Isaac’s view
(c) Alice’s view
Collaborators
Collaborators
Collaborators
Isaac
Isaac
WriterReachable if possible
Development
Instant Messenger
Sandy
Isaac
Writer
Development
Sandy
Reviewer
Conclusions
Development
Instant Messenger
Sandy
Reviewing
Busy
Conclusions
Private Annotations
Reviewer
Accessible
Conclusions
Voice
E-mail
Alice
Alice
WriterAccessible
Conclusions
Private Annotations
Instant Messenger
Alice
WriterAccessible
Conclusions
Video-conference
Writing
Conclusions
Voice
Instant Messenger
Figura 4.11: Disponibilidad y medios de contacto al inicio de la sesión colaborativa.
(a) Sandy’s view
(b) Isaac’s view
(c) Alice’s view
Collaborators
Collaborators
Collaborators
Isaac
Isaac
Writing
Accessible
Development
Video-conference
Isaac
Writer
Development
Development
Instant Messenger
Voice
Sandy
Instant Messenger
Sandy
Sandy
Writing
Accessible
Development
Private Annotations
Writer
Development
Development
Voice
E-mail
Alice
Alice
WriterAccessible
Conclusions
Video-conference
Instant Messenger
Alice
WriterAccessible
Conclusions
Video-conference
Voice
Voice
Instant Messenger
Instant Messenger
Writing
Conclusions
Figura 4.12: Disponibilidad y medios de contacto de Sandy, Isaac y Alice una vez que Sandy
ha cambiado su actividad.
Las variables contextuales involucradas en la adaptación de la disponibilidad y el medio de
contacto son las siguientes: 1) similaridad de las actividades, 2) objetos compartidos en uso y
3) dispositivo en uso. Las variables anteriores son necesarias tanto para la disponibilidad como
el medio de contacto, aunque este último también requiere la disponibilidad y las preferencias
del usuario. Dichas variables están planteadas a detalle en la propuesta 4.6.
La ”similaridad de las actividades“ se refiere a obtener un solo valor que representa dicha
similaridad, para realizar ese cálculo se requiere la actividad actual del colaborador observado
108
y del observador. La similaridad puede tomar alguno de los siguientes valores: muy similares,
similares, mas o menos similar, poco similar, muy poco similar y no similar.
La variable ”objetos compartidos“ en uso, debe contener el objeto que está usando el observado y los que está utilizando el observador. La variable dispositivos en uso debe contener tanto
el hardware como el software del dispositivo en uso del observador como del observado, con la
finalidad de encontrar los dispositivos disponibles para ejecutar los medios de comunicación.
La variable contextual ”disponibilidad“ solo es requerida para calcular el medio de contacto,
dicha variable contiene unos de los siguientes estados: ocupado, accesible y alcanzable si
es posible
La variable ”preferencias“ del colaborador solo involucra las del colaborador observado, la
cuales fueron previamente establecidas por él o por algún mecanismo del sistema.
Proceso de disponibilidad y medios de contacto
Los medios de contacto disponibles en este caso de estudio corresponden a: mensajerı́a instantánea, video conferencia, voz, y anotaciones privadas.
La siguiente lista de eventos muestra el la manera en que la herramienta puede adaptarse a
cambios contextuales
1. El colaborador prefiere que el espacio de trabajo determine su disponibilidad y
medio de contacto. En este caso el colaborador omite abrir la ventana de disponibilidad,
lo cual indica al espacio de trabajo determinar automáticamente esta.
2. Un colaborador coloca su cursor en la foto de otro colaborador. En consecuencia,
la barra de colaboradores despliega varios widgets que muestran la disponibilidad y los
medios de contacto del colaborador observado (cf. Figuras 4.11 y 4.12).
3. El colaborador observador selecciona un medio de contacto del colaborador
observado. Después de seleccionar el medio de contacto, el respectivo medio de contacto
es ejecutado para ser usado por ambos colaboradores.
4.7
Escenario 5: Ocultar información
El objetivo de esta propuesta es ocultar información de manera automática ante la presencia
de una persona ajena al grupo de colaboración
Capı́tulo 4
4.7.1
109
Preámbulo
Frecuentemente la cobertura del servicio de Internet se va incrementando, dicho incremento ha
permitido que los usuarios de ese servicio puedan comunicarse fácilmente. Dentro del grupo de
estos beneficiarios se encuentran los usuarios de los sistemas cooperativos. Gracias a la cobertura de Internet y a los dispositivos móviles, tales como PC portátiles o tablets, los colaboradores
pueden trabajar fuera de sus oficinas.
El problema de trabajar fuera de las oficinas es que los colaboradores pueden acceder a la
información confidencial, desde cualquier lugar, e.g., salones de juntas o bibliotecas. Dicha
información puede ser visualizada por cualquier persona que se acerque al dispositivo. En este
caso el sistema debe interrumpir su funcionamiento de tal forma que oculte el trabajo realizado
hasta el momento, i.e., si la información está desplegada, el sistema deberá cambiarla por otra
información. Otra consecuencia resultante a partir de que una persona ajena se acerque al
dispositivo es la interrupción de la comunicación.
4.7.2
Supongamos que una empresa de desarrollo de software recibió un reporte de un error grave
en un sistema de administración que ellos desarrollaron. Dada la gravedad del problema, la
empresa de desarrollo lanzó una convocatoria a todos sus desarrolladores con la finalidad de
encontrar y proponer una solución a dicho error de software. Por su parte, dicha empresa
premiará al grupo que resuelva el problema.
Un grupo de colaboradores, compuesto por Sandy, Alice e Isaac, encontraron el problema en el
software. Ası́ que ellos decidieron hacer un documento explicando tanto los errores encontrados
ası́ como la solución propuesta mediante diagramas de clases y diagramas de estado. Para la
redacción del documento usan un editor cooperativo.
Después de que el grupo decide el contenido del reporte, ellos se reparten la redacción del
documento de la forma siguiente: Sandy tiene asignada la tarea de escribir los errores encontrados; Isaac debe hacer y describir los diagramas de clase, y Alice tiene que hacer y redactar
los diagramas de estado.
Debido a que el grupo de colaboradores pasó mucho tiempo en una oficina buscando la
solución; ellos deciden trabajar de manera distribuida en la redacción del documento. Sandy
se retira de la oficina, en donde estaban trabajando, para salir a comer en el comedor de la
empresa. Ella decide empezar a trabajar en la redacción del documento mientras espera que
le entreguen su comida. Cuando ella va a la mitad de la redacción le surgen dudas de los
errores encontrados en el software, ası́ que ella decide entablar una comunicación con el resto
del grupo por medio de la mensajerı́a instantánea, la cual forma parte del editor. Mientras el
grupo de trabajo está participando en la conversación, Sandy puede ver en su pantalla tanto el
documento que están generando ası́ como la conversación del grupo. Dentro de la conversación,
110
Sandy hace una pregunta al resto del equipo.
Poco tiempo después de iniciada la comunicación, un programador ajeno al equipo se acerca
a platicar con Sandy. Dicho programador sabe que el equipo de ella ha encontrado tanto
el error como la solución al problema de software, por tal motivo él decide acercarse a la
computadora portátil de ella para intentar leer tanto el reporte como su conversación con el
equipo. Tan pronto el programador se acerca a la computadora, el sistema del editor detecta
que una persona ajena al grupo está observando de frente la pantalla de la computadora de
Sandy. Como consecuencia el sistema oculta tanto el reporte como la conversación que ella
lleva a cabo.
Por otro lado, Alice responde a la pregunta generada por Sandy; pero observa que Sandy no
responde a la explicación dada. De repente Alice nota que la foto de Sandy cambio de color.
Cuando Alice ubica su cursor del ratón sobre la foto de Sandy, el sistema muestra un mensaje
indicando que una persona ajena al grupo está observando la pantalla de Sandy. Por tal motivo
ella no puede observar los mensajes enviados ni las actualizaciones, ası́ como tampoco puede
desarrollar sus actividades.
Este escenario solo se adapta a la dimensión entorno compartido, la cual pertenece al contexto de uso de los sistemas cooperativos. Tal adaptación se logra cuando se detecta una
persona, ajena al grupo de trabajo, cerca de un despliegue de información confidencial. Otra
manera de adaptarse a la dimensión mencionada se hace al notificar a los colaboradores involucrados en la conversación de Sandy acerca de la presencia de una persona ajena al sistema.
4.8
Escenario 6: Adaptar la información
El objetivo de esta propuesta es adaptar la información al contexto.
4.8.1
Preámbulo
La adaptación de la información se hace considerando:
• tiempo: refiere a recibir/enviar información instantáneamente o estableciendo una fecha.
Por ejemplo, un grupo de colaboradores necesitan recibir información de manera inmediata ya que esta influye en su actividad actual; pero en otras ocasiones, la información no
es tan urgente como para recibirla de manera inmediata, como en el caso de las reuniones
de trabajo;
• rol: determina la información a proveer;
Capı́tulo 4
111
• actividad: concierne a proveer información que enriquezca la actividad actual del colaborador, e.g., proveer manuales de diagramas de clase a un colaborador que está haciendo
dichos diagramas;
• conjunto de plataformas: se refiere a considerar tanto al hardware como software necesario para soportar la información;
• Tama~
no de los archivos: un factor importante que se debe considerar, ya que no vale
la pena enviar información muy grande en un dispositivo con pocas capacidades, e.g.,
teléfono inteligente;
• ubicación del colaborador: se refiere a predecir el tipo de información que puede ser
útil para el colaborador considerando su ubicación actual;
• preferencias sobre la información: se refiere a que dada la especificación del colaborador puede recibir información relacionada.
4.8.2
Supongamos que Sandy, Alice e Isaac están registrados en el sistema de consultas a pacientes de
un hospital, cada uno de ellos tienen los siguientes roles: Isaac es médico cardiólogo, mientras
Alice es pasante de medicina y Sandy es enfermera.
Dado que Alice es pasante de medicina, Isaac quiere que ella deduzca el padecimiento de
cinco pacientes. Ası́ que Isaac agenda una cita mediante una agenda cooperativa perteneciente
al hospital. En dicha agenda, Isaac establece la fecha (10 de septiembre del año en curso),
la hora (9 am), el asunto (visita a los pacientes de los cuartos 2, 8, 15, 18 y 19), el lugar
de reunión (sala común de médicos) y los participante (en este caso se agrega él mismo y a
Alice). Al momento de llenar los campos anteriores y seleccionar el botón crear cita, la agenda
cooperativa envı́a una notificación a los participantes.
Alice recibe la notificación de la reunión a través de su celular. Adjunto a la notificación, se
despliega un mensaje para que ella confirme o se rechace la cita; en este caso, Alice confirma
su asistencia a la reunión.
Alice acude en la fecha indicada al hospital desde uno hora antes, ya que ella tiene que hacer
varios trámites para ingresar al sanatorio. Cuando Alice acude al hospital siempre lleva consigo
su IPad, la cual fue previamente registrada en el hospital y actualizada con las aplicaciones que
manejan los médicos de aquel lugar.
Dado que se acordó una cita por medio de una agenda cooperativa, la aplicación envı́a un
recordatorio de la cita una hora antes de la reunión. En dicho recordatorio se puede incluir
el envı́o de información, e.g., los expedientes de los pacientes a revisar, dicho envı́o depende
del contexto del colaborador. Analizando el caso de Alice, el sistema provee la información
al detectar lo siguiente: Alice se encuentra dentro del hospital, la cita que tiene con el Dr.
112
Isaac está por llevarse a cabo en una hora, ella tiene el rol de médico pasante. En el caso que
ella no estuviera dentro del hospital, el sistema por cuestiones de seguridad solo proveerá un
expediente reducido sin resultados de estudios.
Como Alice se encuentra en el hospital, el sistema envı́a por cada paciente a revisar un expediente que tiene anotaciones, e.g., del Dr. Isaac (cardiólogo) y del Lic. Edgar (Nutriólogo),
y estudios médicos del paciente. Dadas las capacidades limitadas del dispositivo de cómputo
que utiliza Alice, iPad, la agenda le envı́a los últimos estudios (desde dos dı́as atrás), e.g., electrocardiograma, ecocardiograma y ergometrı́a, dejando de lado los estudios anteriores. Gracias
a que la aplicación provee los expedientes a los asistentes a la reunión, Alice empieza a revisar
cada uno para estar más involucrada.
Por otro lado, el Dr. Isaac se encuentra en su oficina usando su computadora de escritorio,
ası́ que la información que le llega a dicho dispositivo es diferente que la de Alice. Isaac
recibe los expedientes en una versión reducida porque el estableció dentro de sus preferencias
dicha acción. Isaac decide dicha preferencia por dos razones: 1) él puede ingresar al sistema en
cualquier momento para ver los expedientes completos, y 2) él visita a diario a dichos pacientes.
El contenido de los expedientes que recibe el Dr. Isaac es el siguiente: las anotaciones de colegas
de los dos últimos dı́as, ası́ como los análisis y estudios de una semana anterior a la fecha y
los signos vitales tomados desde la noche anterior. Al momento de que el Dr. Isaac sale de su
oficina lleva consigo su iPad e ingresa al sistema del hospital desde el dispositivo mencionado.
Una vez que Isaac y Alice se reúnen, ellos empiezan su recorrido por las patologı́as más
comunes, en este caso por el paciente del cuarto 18. Al ingresar al cuarto, el sistema del
hospital detecta la presencia de ambos en dicho cuarto; en consecuencia el sistema le propone
al Dr. Isaac delegar algunas responsabilidades a Alice, pero él declinaba la sugerencia ya que
él piensa que ella necesitaba practicar más.
Otra acción por parte del sistema es desplegar en ambas iPad’s el expediente del enfermo del
cuarto dieciocho. Para Isaac es normal tener el expediente del paciente la que visita; en cambio,
Alice se sorprende porque ella tenı́a previamente a la vista el expediente del paciente del cuarto
dos, puesto que ella pensó el recorrido en un orden ascendente. Tanto Alice como Isaac pueden
ver los resultados de los estudios clı́nicos. Terminando la visita, el Dr. Isaac agrega anotaciones
y modifica la dosis de medicamento, a consecuencia de la mejora del paciente, en el expediente
del enfermo. Alice puede ver a través de su iPad la serie de pasos que el Dr. Isaac hace al
momento de modificar el expediente.
Al instante que la dosis es modificada, el sistema del hospital actualiza la información en
la base de datos y al personal que atiende al paciente de la cama 18, e.g., la nueva dosis de
medicamento se notifica a la enfermera Sandy y la mejora en la salud del paciente se notifica
al nutriólogo. La actualización de la dosis es de manera inmediata ya es esta es de vital
importancia debido a que una dosis no apropiada puede tener consecuencias fatales en la salud
del paciente.
En las visitas a los cuartos 8 y 19, Alice continua dando sugerencias verbales y observando
Capı́tulo 4
113
como el doctor responsable manipula el sistema. Cuando ambos llegan al cuarto 15, el Dr. Isaac
decide que Alice puede empezar a participar en las anotaciones dentro del sistema mediante las
sugerencias del sistema. Por tal motivo, ambos tienen derechos de modificar el expediente de
dicho paciente.
Finalmente, ellos acuden al cuarto dos en donde la enfermera Sandy está tomando los signos
vitales del paciente del cuarto. Cuando ellos ingresas al cuarto, la información de los signos
vitales es actualizada inmediatamente a los iPad’s de Alice e Isaac. Al momento que el sistema
detecta que ambos están en el cuarto, el sistema propone dos opciones: 1) delegar algunas
responsabilidades a Alice o 2) usar la computadora táctil que se encuentra sobre la pared.
Ambas opciones solo son desplegadas al Dr. Isaac pues él tiene un rol de mayor jerarquı́a que el
rol de Alice. Isaac accede a las dos opciones, por tal motivo Alice puede modificar el expediente
bajo la supervisión del doctor, dicha supervisión es permitida desde su iPad. Por otro lado, el
sistema despliega todas las ecocardiogramas y electrocardiogramas en la computadora táctil,
ya que es muy usual dicha preferencia. Mientras que las iPads solo contienen las anotaciones
médicas.
Al terminar las visitas y cada uno seguir con otras actividades, el sistema no permite que
Alice consulte los expedientes de los pacientes visitados; en cambio, el Dr. Isaac tiene acceso
total en cualquier momento, mientras él se ubique dentro del hospital. En otros lugares, el Dr.
Isaac no puede ver información restringida, e.g., anotaciones del nutrı́lago.
Este escenario aborda todas las dimensiones del contexto de uso de los sistemas cooperativos. La
adaptación al grupo de colaboradores se implementa al proveer la información relacionada a
los roles, al respetar los grupos estratificados (Isaac tiene el control de permitir la intervención
de Alice dentro del sistema del hospital) y las preferencias de los usuarios (Isaac decidió que el
sistema le provea de información actual, a lo más con dos dı́as de anterioridad).
La adaptación al conjunto de plataformas se presenta al momento de sugerir usar la
pantalla táctil cuando están en un cuarto que tiene dicha pantalla. También se puede ver esta
dimensión que ha sido llevada a cabo cuando el sistema provee solo la información más actual
a Alice, dadas las caracterı́sticas de su dispositivo.
La adaptación al entorno compartido se aprecia en este escenario, ya que se considera, el
lugar (proveer la información solo cuando los colaboradores estén dentro del hospital, ası́ como
mostrar en pantalla el expediente del paciente que están actualmente visitando) y el tiempo
(proveer la información una hora antes de la reunión).
114
4.8.3
Herramienta administrador de contenidos vı́a NFC
Esta aplicación nos permite facilitar a un grupo de colaboradores la información que se va a
tratar en una reunión previamente planificada. Dicha información se refiere al objetivo de la
reunión, los temas a tratar y los archivos relevantes a la misma. Al entrar al lugar de reunión y
acercar su dispositivo móvil a la etiqueta NFC asociada a dicho lugar, los colaboradores reciben
automáticamente toda la información sobre la reunión y los archivos que se discutirán durante
la misma.
Está aplicación fue
[Romero et al., 2013].
desarrollada
en
colaboración
de
un
alumno
de
maestrı́a
Los requerimientos funcionales del administrador de contenidos vı́a NFC se presentan a continuación:
1. Permitir que un colaborador ingrese la información relacionada a una reunión y suba a
un servidor de contenidos, los archivos que son relevantes a la misma.
2. Permitir que un colaborador pueda grabar la información relacionada a una reunión en
una etiqueta NFC.
3. Permitir que un colaborador, al acercar su dispositivo a una etiqueta NFC, inicie automáticamente su sesión y reciba en su dispositivo la información referente a una reunión.
4. La aplicación debe ejecutarse automáticamente cuando un colaborador inicie sesión por
medio de una etiqueta NFC y haya información sobre una reunión en la etiqueta.
5. Adaptar la interfaz de usuario de acuerdo a la información recibida, e.g., la interfaz
muestra la lista de puntos a tratar en la reunión y la información adicional correspondiente
a cada uno de ellos.
6. Detectar los tipos de formato de documentos soportados por las herramientas instaladas
en el dispositivo.
7. Detectar los tipos de formato de documentos soportados por las herramientas instaladas
en el dispositivo.
8. Iniciar la descarga de los documentos que es necesario revisar durante una reunión. Durante la solicitud de los documentos, se debe indicar qué tipos de formato de documentos
son soportados, de tal manera que los documentos a descargar sean en un formato soportado.
Capı́tulo 4
115
9. Mostrar en la interfaz de usuario de la aplicación un ı́cono que represente el documento
descargado y permitir abrir dicho documento al hacer clic sobre su ı́cono.
Los requerimientos no funcionales del administrador de contenidos vı́a NFC se listan a continuación:
1. Habilitar el adaptador de red inalámbrico WiFi, si éste se encuentra deshabilitado.
2. Permitir la apertura de los archivos descargados.
3. Garantizar la integridad y consistencia de toda la información transferida.
4. No permitir la transmisión de la información a dispositivos de usuarios que no se encuentren registrados.
Interfaz de usuario
La aplicación lleva a cabo la adaptación de la información recibida, ya que es consciente de
otras herramientas para visualizar documentos con las que cuenta el dispositivo. Hace uso de
esta información al solicitar los documentos al servidor, de manera que sólo sean descargados
documentos en un formato soportado.
La aplicación consta de un módulo para leer y uno para grabar las etiquetas. A continuación
se presenta una descripción sobre dichos módulos:
1. módulo de escritura: es usado para grabar la información relacionada a una reunión en
la etiqueta, ası́ como la información de archivos subidos al servidor que son relevantes a
la misma (cf. Figura 4.13a);
2. módulo de lectura: está diseñado para leer las etiquetas y es ejecutado cada vez que el
dispositivo reconoce una etiqueta NFC (cf. Figura 4.13b).
En este aplicación hacemos uso de la tecnologı́a NFC para habilitar otros tipos de comunicaciones, e.g., WiFi y para proveedor contenidos digitales. La información es grabada en
etiquetas NFC por el organizador de la reunión y posteriormente los participantes leen dicha
información al acercar su dispositivo a la misma etiqueta.
Por otro lado, además de identificar lugares con esta tecnologı́a también es posible identificar
objetos, por lo que la aplicación provee consciencia de localización a grano fino, e.g., un pizarrón
interactivo.
116
(a) Módulo de escritura
(b) Módulo de lectura
Figura 4.13: IU del administrador de contenidos
Proceso de interacción con el administrador de contenidos
Durante el proceso, la aplicación pasa a través de tres fases principales, las cuales se describen
a continuación:
• Nueva reunión: desde su dispositivo móvil, un colaborador ejecuta la aplicación administrador de contenidos vı́a NFC. Como resultado a esta acción, se muestra el módulo de
escritura. En este módulo, se presenta una interfaz de usuario que muestra: 1) un campo
de texto donde se puede escribir el objetivo de la reunión, 2) un botón y un campo de
texto para establecer la hora y la duración de la reunión, respectivamente, 3) botones
para agregar o eliminar temas a tratar durante la reunión, 4) la lista actual de los temas,
junto con los archivos relacionados a cada uno y 5) un botón para grabar la etiqueta. En
la Figura 4.13a se muestra la interfaz de usuario del módulo de escritura de la aplicación.
• Grabación de etiqueta: después de haber ingresado la información de la reunión y
haber subido los archivos al servidor, se debe grabar la etiqueta. Para esto, solo necesi-
Capı́tulo 4
117
tamos acercar el dispositivo a la etiqueta y seleccionar la opción “Grabar etiqueta” de la
interfaz de usuario.
• Adaptación de información (lectura de etiqueta): cuando un usuario “toca” alguna
de las etiquetas NFC grabadas con el módulo de escritura de la aplicación, el dispositivo
lee la información almacenada en la etiqueta y tienen lugar los siguientes eventos: 1) se
verifica el estado de la conexión WiFi, si está deshabilitado el adaptador, se habilita y se
trata de conectar a un punto de acceso, 2) se inicia automáticamente la sesión del usuario,
3) se ejecuta el módulo de lectura de la aplicación en el dispositivo móvil y 4) se muestra,
ya sea la lista de reuniones planificadas o si hay una reunión en curso. Si el usuario elige
participar en la próxima reunión o en la reunión en curso, la interfaz de usuario de la
aplicación es adaptada con la información sobre la reunión, i.e. se muestra la lista de
puntos a tratar en la reunión, el objetivo de la reunión y los archivos que son relevantes
a la misma. En caso de que el usuario decida no participar, su sesión es finalizada. En
la figura 4.13b se muestra la interfaz de usuario del módulo de lectura de la aplicación,
donde se muestra la información sobre la reunión en curso.
Los archivos que es necesario revisar durante la reunión no son almacenados en las etiquetas
NFC, debido a las limitaciones de almacenamiento de dichas etiquetas. Por tal motivo, se
solicita al servidor la descarga de los mismos por medio de Wi-Fi. Previamente, la aplicación
identifica que tipos de formatos de documento son soportados por las herramientas con las
que cuenta el dispositivo. Por lo tanto, durante la solicitud de descarga de un documento, se
indican los formatos de archivo soportados por el dispositivo, de tal manera que el documento
a descargar sea en un formato soportado (si está disponible). Al finalizar la descarga, en la
interfaz de usuario de la aplicación, se muestran junto a cada tema de la reunión, los documentos
descargados asociados a cada uno. Finalmente, por medio de un clic sobre cada elemento se
puede visualizar el contenido del documento.
Con el fin de mostrar la manera en que el administrador de contenidos puede adaptarse a los
cambios contextuales, se describe una lista de eventos que provocan adaptación.
1. Un colaborador ingresa a una sala de juntas y acerca su dispositivo (a una distancia de
3 cm o menos) a una etiqueta NFC: se inicia automáticamente la sesión del usuario, se
ejecuta la aplicación administrador de contenidos vı́a NFC en su dispositivo móvil y la
etiqueta transfiere al dispositivo del usuario la información referente a una reunión. La
interfaz de usuario de la aplicación es adaptada de acuerdo a la información recibida, i.e.
la interfaz de usuario muestra la lista de puntos a tratar en la reunión y la información
adicional correspondiente a cada uno de ellos. Se inicia la descarga de los documentos
que es necesario revisar durante la reunión.
2. La aplicación detecta que tipos de formatos de documento son soportados por las aplicaciones con las que cuenta el dispositivo: durante la solicitud de descarga de un documento
del servidor se indican los formatos de archivo soportados por el dispositivo, de tal manera
que el documento a descargar sea en un formato soportado (si está disponible).
118
3. Termina la descarga de los documentos que es necesario revisar durante la reunión: en
la interfaz de usuario de la aplicación se muestra un ı́cono que representa el documento
descargado y por medio de un clic sobre dicho ı́cono se puede abrir el documento para
ver su contenido.
4.9
Escenario 7: Uso de diferentes modalidades en la
notificación
El objetivo es proveer a las notificaciones de diversas modalidades para que dichas avisos se
adapten al contexto.
4.9.1
Preámbulo
La modalidad nos puede permitir dar a conocer la llegada de información de diferentes formas
dependiendo del tipo de información a notificar, el lugar en donde se encuentra ubicados los
colaboradores e incluso las personas a nuestro alrededor. Las notificaciones multi-modales más
usadas en los celulares son por: sonidos, cuadros de texto o vibración.
En un ambiente colaborativo es fundamental informar sobre eventos importantes para el
grupo, e.g., cambio de medicamento a un paciente. La modalidad a usarse para notificar la
información debe adaptarse dependiendo varios parámetros, los cuales son los siguientes:
• la relevancia de la información, e.g., es más importante notificar a una enfermera el cambio
de medicamento de un paciente hospitalizado que recibir la notificación de un dispositivo
cercano a la enfermera que permite hacer video-llamadas;
• la actividad del colaborador que origina la notificación y la del colaborador que recibe la
notificación es importantes;
• el lugar fı́sico en donde se encuentra el receptor de la notificación.
4.9.2
Un grupo de colaboradores integrado por Sandy, Alice, Isaac son parte de un equipo de desarrollo de software de una empresa renombrada. Sandy y Alice están exponiendo a los clientes
los avances del proyecto. Mientras tanto, Isaac está terminando una actividad, la cual tenı́a
una fecha lı́mite caducada, que no podı́an resolver. Dicha actividad es importante, ya que es
parte de los avances a presentar frente a los clientes.
Capı́tulo 4
119
El sistema informa mediante notificaciones a los miembros del equipo acerca de las modificaciones y las actividades concluidas en las que están participando.
Antes de emitir la notificación, el sistema determina el modo de la notificación considerando
las siguientes caracterı́sticas: 1) la actividad actual de Alice y Sandy, cuya actividad es la
exposición de los avances del proyecto, 2) las colaboradoras se encuentran en una sala de juntas
con personas ajenas al proyecto, 3) la actividad concluida es de importancia para ellas, 4) los
dispositivos que están usando los colaboradores, en este caso cada uno de ellos tiene un teléfono
celular, ası́ como dos computadoras portátiles, una de ellas la usa Isaac, mientras que la otra
es usada por Alice y Sandy.
En consecuencia, el sistema desvı́a la notificación textual hacia el teléfono celular de ambas
colaboradoras usando la vibración de los celulares y la emisión de un sonido en un nivel apenas
perceptible para avisarles de la llegada de una notificación. Mientras Alice continua explicando,
Sandy decide leer la notificación, ya que notó que tanto ella como Alice recibieron una notificación al mismo tiempo. Dicha noticia informa de la conclusión de la actividad pendiente, la
cual puede ser mostrada por completo al cliente.
El sistema notifica a Isaac que sus colegas han terminado la exposición mediante una mensaje
textual en la computadora. La notificación no emite sonido alguno y solo despliega en la parte
inferior derecha de la pantalla un recuadro que contiene el anuncio. El sistema notifica de este
modo a Isaac considerando que tiene en uso una computadora, que esta en su oficina y que la
actividad de él no es de gran importancia dada la fecha lı́mite de la actividad.
Isaac quiere saber sobre los resultados de la presentación con los clientes, por tal motivo él
hace una reunión en su oficina mediante una agenda cooperativa. Él establece el lugar de reunión
su oficina. Por tal motivo, la agenda informa a Sandy y Alice de dicha reunión de manera
textual, mediante sus teléfonos celulares. En esta ocasión, el sistema utiliza nuevamente la
vibración del celular además de aumentar el timbre de la notificación ya que ellas temporalmente
no están desarrollando una actividad y se encuentran en los pasillos del edificio.
Después de la reunión con Isaac, las colaboradoras se dirigen cada una a sus oficinas para
continuar trabajando en las actividades asignadas. Sandy se encarga de los diagramas de clase,
ası́ que ella no requiere ni recibir las notificaciones de actualización del diagrama de estado ni
que se realicen automáticamente las actualizaciones de dichos diagramas (suponiendo que el
dispositivo de computo no cuente con los recursos necesarios de espacio en disco duro, poca
memoria RAM o que la intensidad de la señal de Internet sea demasiado débil como para
soportar la transferencia de archivos demasiado grandes), ya que en muchas ocasiones se vuelve
lenta su aplicación en uso. El sistema debe esperar a que Sandy seleccione ver los diagramas
de estados para notificarle dichas actualizaciones, además el sistema debe revisar si realizó las
actualizaciones de dichos diagramas o tiene que hacer la petición de las actualizaciones.
120
Este escenario se adapta a todo contexto de uso de los sistemas cooperativos. Se adapta al
grupo de colaboradores ya que verifica la actividad en desarrollo, i.e., envı́a la notificación
del termino de la actividad de Isaac.
Se adapta al conjunto de plataformas porque decide sobre que dispositivo se enviara la
notificación.
Se adapta al entorno común porque considera el lugar en donde se encuentra los colaboradores, ası́ como la presencia de persona ajenas al grupo de trabajo, de este modo la notificación
es silenciosa.
4.10
Aplicaciones de prueba
Las cinco aplicaciones presentadas en esta sección han sido implementadas para soportar el
trabajo cooperativo, algunas de ellas permiten tanto el trabajo co-localizado como el distribuido,
pero otras solo una de esas dos opciones.
Las herramientas que permiten el trabajo co-localizado como distribuido corresponde a:
herramienta de votación y herramienta editor cooperativo de mapas mentales. Ambas herramientas comparten tanto un espacio de trabajo en donde son ejecutada como una sola la
barra de colaboradores. Dicha barra se adapta dependiendo del modo de trabajo.
Las herramientas que solo soportan el trabajo distribuido corresponden a la herramienta
sugerencia proactiva y la herramienta de disponibilidad y medios de contacto. La herramienta
sugerencia proactiva permite ejecutar tres aplicaciones y crear ligas entre objetos compartidos.
La herramienta barra disponibilidad y medios de contacto permiten adaptar dichos componentes, disponibilidad y medios de contacto, considerando las actividades de los colaboradores
involucrados, i.e., el colaborador que desea saber la disponibilidad de otro colaborador.
La herramienta administrador de contenidos vı́a NFC solo permite el trabajo co-localizado.
Dicha herramienta provee documentos relacionados a una reunión, considerando la fecha de la
reunión.
4.10.1
Herramienta de votación
Esta aplicación intenta facilitar y agilizar el proceso de una sesión de votación, permitiendo a
los votantes ejercer su voto de manera electrónica mediante sus dispositivos móviles, ya sea que
se encuentren en el lugar de votación (colocalizados) o en un cualquier otro lugar (distribuidos).
Está
aplicación
fue
desarrollada
en
colaboración
de
un
alumno
de
maestrı́a
Capı́tulo 4
121
[Romero et al., 2013].
Los requerimientos funcionales y no funcionales de esta aplicación serán tratados en esta sección.
Los requerimientos funcionales se describe a continuación:
1. Identificar y asignar el rol a cada usuario con base al tipo de dispositivo desde el cual
acceden a la aplicación.
2. Adaptar su IU de acuerdo al rol del usuario y del modo de trabajo co-localizadamente o
distribuida.
3. Permitir que el proponente organice una nueva votación. En particular, se le debe permitir
plantear una pregunta hacia el grupo de colaboradores mediante un pizarrón interactivo.
Determinar las posibles opciones de respuesta para la pregunta, establecer si la votación
puede ser anónima o no, definir el porcentaje mı́nimo para hacer válida la votación y
establecer un tiempo de espera para que los usuarios emitan su voto.
4. Mostrar en los dispositivos móviles tanto de los miembros virtualmente presentes como
de los miembros fı́sicamente presentes, las posibles opciones de respuesta a la pregunta de
la votación, una opción para abstenerse de votar y, si la votación lo permite, una opción
para votar como anónimo.
5. Mostrar en los dispositivos móviles de los miembros virtualmente presentes la pregunta
que fue sometida a votación.
6. Garantizar, siempre que sea posible, la igualdad entre las opciones de voto que aparecen
en pantalla, sin favorecer a ninguna.
7. Mostrar en el pizarrón interactivo la pregunta sometida a votación, ası́ como la información adicional sobre la misma, i.e., si la votación puede ser anónima o no, las posibles
opciones de respuesta para la pregunta, el porcentaje mı́nimo para hacer válida la votación
y el tiempo de espera para que los usuarios emitan su voto.
8. Brindar al proponente la posibilidad de iniciar la votación, lo cual hará posible que se
puedan recibir y registrar los votos de los electores.
9. Mostrar un tiempo de espera en el pizarrón interactivo para que los miembros presentes
y virtualmente presentes emitan su voto.
10. Solicitar al votante la confirmación del voto.
11. Contabilizar los votos de los usuarios y calcular el porcentaje de votación.
122
12. Si no se alcanza el porcentaje mı́nimo de votación, la aplicación debe mostrar opciones
para: 1) validar la votación con el porcentaje actual de votación, 2) posponer la votación
o 3) cancelar la votación.
13. Si se alcanzó el porcentaje mı́nimo de votación o se validó la votación manualmente, la
aplicación debe mostrar los resultados de la votación en el pizarrón interactivo y enviar
los resultados a los dispositivos móviles de los miembros virtualmente presentes.
14. Ser capaz de recuperar una sesión de votación que ha sido establecida como pospuesta.
15. Eliminar toda la información de una sesión de votación establecida como cancelada.
16. Ser capaz de mostrar los resultados de una sesión de votación establecida como válida.
Los requerimientos no funcionales en la herramienta de votación se muestra a continuación:
1. El almacenamiento del voto debe realizarse de manera tal que garantice la privacidad del
voto. No se podrá tener acceso a los votos almacenados antes de que se produzca el cierre
de la votación.
2. La información se debe transmitir de forma que se garantice la integridad y autenticidad
de la misma.
La herramienta de votación provee un conjunto de interfaces de usuario para soportar una
votación electrónica. Los miembros pueden estar reunidos en una área común o distribuidos, o
hı́bridos, i.e., algunos pueden estar reunidos y otros distribuidos. Dicha herramienta explora la
manera en que se debe presentar la información para los colaboradores distribuidos (cf. Figura
4.14b) o co-localizados (cf. Figura 4.14a). En el caso de los colaboradores co-localizados, ellos
verán en sus dispositivos personales solo las opciones que pueden seleccionar, ya que dichos
integrantes están reunidos en un sala de juntas en donde se esta proyectando el tı́tulo; en
cambio, los colaboradores distribuidos necesitan saber el tı́tulo de la votación ası́ como conocer
los participantes que se encuentran reunidos fı́sicamente, virtualmente y los ausentes.
Este herramienta despliega una ventana que permite genera el tı́tulo de la votación, el tiempo
de espera para que los votantes emitan su voto, los posibles candidatos, el porcentaje mı́nimo
para hacer válida la votación, ası́ como permitir que los colaboradores voten de manera anónima
o abstenerse de votar (cf. Figura 4.15).
Después de emitida la votación, los resultados incluyen el porcentaje obtenido por cada
candidato, ası́ como los nombre de las personas que votaron por cada uno; pero no serán
mostrados los nombres de las personas que decidieron votar de manera anónima. Las interfaces
de usuario serán diferentes dependiendo de la ubicación de los colaboradores, e.g., los colaboradores co-localizados podrán ver los resultados en el proyector (cf. Figura 4.16b). En cambio,
Capı́tulo 4
(a) Vistas para los votantes colocalizado
en sus dispositivos móviles
123
(b) Vistas para los votantes distribuidos
en sus dispositivos móviles
Figura 4.14: Adaptabilidad de la interfaz de usuario de la herramienta de votación de acuerdo
a la ubicación del grupo y al rol de votantes
los colaboradores distribuidos verán de diferente forma dichos resultados, e.g., ellos deberán
seleccionar la votación de un candidato para que se despliegue las personas que votaron por
dicho candidato (cf. Figura 4.16a).
En la adaptación al contexto se consideran las siguientes variables contextuales: 1) el rol
del colaborador y 2) la configuración de grupo. Los roles que puede asumir el usuario son: a)
proponente, el cual permite a un usuario plantear una pregunta hacia el grupo de colaboradores
y establecer las reglas de la sesión de votación y b) votante, el cual permite a un usuario
emitir su voto en una sesión de votación en curso. La configuración de grupo puede ser: 1)
co-localizado (fı́sicamente presente), cuando el usuario se encuentra en el lugar de votación y
2) distribuido (virtualmente presente), cuando el usuario se encuentra en un lugar diferente
al lugar donde se lleva a cabo la votación.
124
Figura 4.15: Opciones establecidas por el colaborador proponente en el pizarrón blanco interactivo
Proceso de votación
Para llevar a cabo una sesión de votación, un grupo de colaboradores organiza una reunión en
una sala de juntas que cuenta con una pizarrón interactivo. Durante el proceso de votación la
aplicación pasa a través de tres fases principales, las cuales se describen a continuación:
• Propuesta de votación: cuando un colaborador pasa a la zona donde se encuentra el
pizarrón interactivo, su presencia es detectada y se inicia su sesión. Desde el pizarrón
interactivo, el colaborador selecciona la herramienta de votación, la cual le otorga el rol de
proponente. Mediante dicho rol, el colaborador plantea hacia el grupo de colaboradores
la pregunta a votación y establece las reglas de la misma. En la figura 4.15 se muestra la
interfaz de usuario con las opciones disponibles para el proponente.
• Votación: una vez que el proponente ha iniciado la votación, los usuarios reciben en sus
dispositivos una notificación de votación. Al seleccionar dicha notificación la aplicación
se ejecutará automáticamente mostrando una interfaz de usuario adaptada de acuerdo
al contexto de uso del usuario. Mediante IU el usuario podrá emitir su voto y éste será
enviado al servidor. En la figura 4.14a se muestra la interfaz de usuario adaptada para
los votantes que se encuentran co-localizados y en la figura 4.14b la interfaz de usuario
para los votantes que se encuentran distribuidos.
• Conteo y publicación de resultados: después de que el tiempo de espera ha finalizado,
la aplicación lleva a cabo el conteo de votos. Si el porcentaje de votación fue alcanzado,
los resultados serán mostrados en el pizarrón interactivo y enviados a los dispositivos
Capı́tulo 4
(a) Resultados mostrados a los
votantes distribuidos
125
(b) Resultados mostrados a los votantes co-localizados
Figura 4.16: Adaptabilidad de los resultados de votación de acuerdo a la localización de los
votantes.
126
móviles de los usuarios que votaron de manera remota. Por el contrario, si el porcentaje
mı́nimo no fue alcanzado, se mostrará un diálogo donde el proponente tendrá que elegir
si desea validar con el porcentaje de votación actual, posponer o cancelar la votación.
En las figuras 4.16b y 4.16a se muestran los resultados de votación mostrados tanto en
el pizarrón interactivo como en los dispositivos móviles de los participantes virtualmente
presentes (distribuidos).
Con el fin de mostrar la manera en que la herramienta de votación puede adaptarse a los
cambios contextuales, se describe una lista de eventos que provocan adaptación.
1. Un proponente inicia una nueva sesión de votación: cuando un proponente inicia
una nueva sesión de votación se envı́a una notificación de votación a los dispositivos
móviles de los participantes presentes y virtualmente presentes, a quienes se les asigna el
rol de votante. Además, el pizarrón interactivo muestra un tiempo de espera para que los
participantes presentes y virtualmente presentes emitan su voto.
2. Un participante virtualmente presente participa en la sesión de votación:
cuando un participante virtualmente presente selecciona la notificación de votación, se
ejecuta la herramienta de votación en su dispositivo y adapta su interfaz de usuario
mostrando tres listas de conciencia de grupo: 1) ausentes, 2) virtualmente presentes y 3)
fı́sicamente presentes en la reunión; además, muestra la pregunta, sus opciones de respuesta y su información adicional, e.g., si la votación puede ser anónima o no. Cuando
un participante presiona durante 1 o 2 segundos una de las opciones de respuesta, se
muestra un mensaje emergente que proporciona información adicional sobre la opción
seleccionada.
3. Un participante fı́sicamente presente participa en la sesión de votación: cuando
un participante fı́sicamente presente selecciona la notificación de votación, se ejecuta la
herramienta de votación en su dispositivo y adapta su interfaz de usuario desplegando
únicamente las posibles opciones de respuesta para la pregunta actual, y, si es el caso,
muestra una opción para votar como anónimo y un botón de abstención.
4. Se termina el tiempo de espera para emitir los votos: sı́ la aplicación detecta que
se alcanzó el porcentaje mı́nimo establecido de votación, la votación es establecida como
válida y se muestran los resultados. En caso de que no se haya alcanzado el porcentaje
mı́nimo de votación, la aplicación muestra un mensaje de aviso en el pizarrón interactivo
que proporciona las siguientes opciones: 1) validar la votación con el porcentaje actual
de votación, 2) posponer la votación o 3) cancelar la votación.
5. Una sesión de votación ha sido validada: cuando termina una sesión de votación y
es validada ya sea de manera manual o automáticamente, se muestran los resultados en
el pizarrón interactivo y se envı́an los resultados de la votación a los dispositivos móviles
de los participantes virtualmente presentes. Esta adaptación se lleva a cabo con base
en la configuración grupo, para los participantes fı́sicamente presentes, no es necesario
Capı́tulo 4
127
enviar los resultados de la votación a sus dispositivos debido a que son mostrados en el
pizarrón interactivo, a diferencia de los participantes virtualmente presentes los cuales no
tienen visión de dicho despliegue. Además tanto en el pizarrón interactivo como en los
dispositivos móviles de los participantes virtualmente presentes se visualiza el porcentaje
de votación de cada opción, ası́ como los participantes que votaron por cada una de ellas.
La aplicación adapta la manera en que se muestran los resultados ocultando algunos
detalles en los dispositivos móviles, debido a las dimensiones de la pantalla de despliegue.
6. Una sesión de votación ha sido pospuesta: cuando termina una sesión de votación
y es establecida como pendiente, se agrega a la lista de votaciones pospuestas, de donde
se podrá reanudar en otro momento.
7. Una sesión de votación ha sido cancelada: cuando termina una sesión de votación
y es establecida como cancelada, se elimina la información correspondiente a la misma.
8. Un proponente reanuda una sesión de votación pospuesta: se envı́a una notificación de votación a cada dispositivo móvil de los participantes presentes y virtualmente
presentes que no han emitido su voto en la votación actual y se les asigna el rol de votante.
De igual manera, el pizarrón interactivo muestra un tiempo de espera para que emitan
su voto.
4.11
Conclusiones
Puede observarse que existe cierta similitud entre la dimensión usuario y grupo de colaboradores, en donde la primera pertenece los sistemas mono-usuario y la segunda a los sistemas
cooperativos. Ambas dimensiones incluyen el perfil, las actividades y los roles; la diferencia radica en que la adaptación al usuario modifica las necesidades y preferencias de un solo usuario,
i.e., solo el sistema de dicho usuario se ve afectado sin modificar los sistemas de los demás
usuarios; mientras que la adaptación al grupo de colaboradores puede modificar el comportamiento del sistema usado por todos los colaborador, e.g., un usuario puede establecer el
medio de contacto para que sus colegas lo contacten dependiendo su actividad y la plataforma
del colaborador contactado y a contactar.
El contexto de uso de los sistemas cooperativos afectan a todos los colaboradores que están
conectados al sistema, e.g., en el escenario 4.3 se permite ligar objetos compartidos, los cuales
han sido creados desde diferentes aplicaciones, mediante referencias HTML; ası́ como notificar
a los colaboradores cuando hacen uso de manera directa o indirecta del mismo objeto.
Los escenarios mostrados en este capı́tulo nos permiten dar una idea de las adaptaciones del
contexto de uso de los sistemas cooperativo. Dichas adaptaciones se hacen al grupo de colaboradores al considerar sus preferencia relacionadas a los medios de adaptación (cf. Escenario
4.6), dependiendo del rol se puede mostrar los iconos relacionados a su rol cf. Escenario 4.4,
128
información necesaria dependiendo de la actividad en curso (cf. Escenario 4.8) o en otras ocasiones ocultar dicha información que puede ser confidencial (cf. Escenario 4.7). Otra adaptación
al colaborador es presentar notificaciones diferentes modalidades dependiendo de la actividad
o del entorno en donde se ubica (cf. Escenario 4.9).
Dichos escenario no solo cubren la dimensión grupo de colaboradores, también cubren aspecto
de la dimensión plataforma, ya que algunos de ellos identifican cuando el grupo de colaboradores
tiene un conjunto de dispositivos; por ejemplo: activar el medio de contacto de video-conferencia
dependiendo si los colaboradores tienen una cámara en uso, de otra manera no vale la peno
ofrecer el servicio (cf. Escenario 4.6), o permitir usar el disco duro de un colaborador cuando
el dispositivo en uso no tenga suficiente espacio para almacenar la información (cf. Escenario
4.4).
Ası́ como estos escenarios cubren aspectos del domino del grupo de colaboradores o del
conjunto de plataformas; algunos de ellos se adaptan al entorno común, e.g., adaptar la IU
dependiendo el trabajo co-localizado o distribuido (cf. Escenario 4.5) o el detectar la presencia
de una persona no autorizada para ver información restringida (cf. Escenario 4.7).
Algunas de las propuesta mencionadas en lo escenarios han sido implementadas en las herramientas desarrolladas. Por ejemplo adaptar los iconos dependiendo el rol del colaborador (cf.
Herramientas 4.4.3 y 4.3.3), al trabajo co-localizado o distribuido (cf. Herramienta 4.10.1, 4.8.3
y 4.4.3).
Capı́tulo 5
Diseño del marco XARE
En este capı́tulo se describen los diseños horizontal y otro vertical del marco XARE. El diseño
vertical, que se expplica en la sección 5.1, expresa el contexto de uso de los sistemas colaborativos
mediante diagramas de clases (usando UML) y patrones de diseño para que los desarrolladores
puedan implementar dicho contexto.
Antes de dar a conocer el diseño horizontal, se presenta en la sección 5.2 los principales
mecanismos que cumplen los objetivos de los escenarios identificados en el capı́tulo 4. Todos los
mecanismos, que se presentan en dicha sección, contienen los parámetros de entrada necesarios,
las clases involucradas, ası́ como los elementos que son susceptibles a ser modificados.
El diseño horizontal se refiere a las capas del marco de adaptabilidad plástica para sistemas
colaborativos, el cual se aborda en la sección 5.3. El marco XARE propone adaptar los sistemas
colaborativos al contexto de uso, considerando los percutores de adaptación (remodelación y
redistribución) y la participación de los colaboradores durante el proceso de adaptación (metainterfaz con o sin negociación), evitando en todo momento la pérdida (recuperación del sistema).
5.1
Diagramas de clases
El modelado del contexto de uso se puede hacer de diversas maneras, e.g., ontologı́as [Ejigu et al., 2007], grafos contextuales [Kouadri and Brézillon, 2004], teorı́a de actividad [Kofod-Petersen and Cassens, 2006], lógica proposicional de contexto, semántica de
modelo local/sistemas multicontexto [Serafini and Bouquet, 2004] y diagramas de clases
[Derntl and Hummel, 2005]. Para modelar el contexto de uso de los sistemas colaborativos
se eligió los diagramas de clases, ya que estos permiten llevar a cabo la implementación del
contexto mediante lenguajes de programación orientado a objetos. Además, estos diagramas
han sido usados para llevar a cabo modelación visual de conceptos del mundo real, la cual
sirve para reducir la complejidad y la carga cognitiva durante la etapa de diseño de un sistema
129
130
[Henricksen et al., 2002, Derntl and Hummel, 2005].
5.1.1
Diagrama de clase del contexto de uso de los sistemas cooperativos
Como se mencionó, el contexto de uso para los sistemas colaborativos se forma de los elementos grupo de colaboradores, conjunto de plataformas y entorno común. En la
figura 5.1, el contexto de uso de los sistemas colaborativo ha sido modelado mediante el patrón
de diseño Decorator, el cual permite definir dinámicamente nuevos contextos de uso (clase
ContextOfUse) para hacer que los sistemas colaborativos se adapten a cambios contextuales
sin tener que modificar estos (clase AdaptativeGroupwareSystem). De este modo, es posible que sistemas colaborativos no adaptativos (clase ConcreteGroupwareSystem) se vuelvan
conscientes del contexto de uso (clases ContextOfUse 1 ... ContextOfUse n).
Los diferentes contextos de uso pueden incluir todos o algunos de los elementos de adaptación
(grupo de colaboradores, conjunto de plataformas y entorno común) dependiendo
de los requerimientos del sistema. De esta manera, este patrón provee a los programadores con un soporte flexible de desarrollo que les permite enriquecer sus sistemas cooperativos con capacidades de adaptación, involucrando algunos o todos los componentes (clases
GroupOfCollaborators, SetOfPlatforms y CommonEnvironment).
La figura 5.1 muestra un grupo de colaboradores que está compuesto por al menos un colaborador (clase GroupOfCollaborators) quien tiene un perfil y varios roles. De acuerdo a Gauch
et al., un perfil (clase Profile) permite definir las habilidades y preferencias de una persona
[Gauch, et al., 2007]. Las habilidades de un colaborador (clase Skill) se refiere a las capacidades necesarias para llevar a cabo un conjunto de actividades con un cierto nivel de certeza
(atributo dexterityLevel). El rol de un colaborador (clase Role) está definido por un conjunto
de actividades que definen su responsabilidad y alcances.
Las preferencias de un colaborador (clase Preference) conciernen a la elección de opciones
ofrecidas por el sistema colaborativo, e.g., su disponibilidad, sus medios de contacto y la forma
de notificar la información. La disponibilidad de un colaborador (clase Availability) puede
pasar a través de los siguientes estados (atributo state): presente o ausente, pero si el colaborador está presente, él puede estar ocupado, accesible, alcanzable si es posible y disponible. Un
colaborador puede simultáneamente mostrar a sus colegas diferentes niveles de disponibilidad
dependiendo (cf. Mecanismo disponibilidad en la sección 5.2.2) de:
• la similaridad (atributo similarity) entre su actividad actual o potencial y la de sus
colegas que perciben su estado de disponibilidad;
• la fecha lı́mite (atributo timeSlot) de su actividad actual.
Como se muestra en la Figura 5.1, una actividad (clase Activity) es un conjunto de acciones
Capı́tulo 5
131
Has
SetOfPlatforms
GroupOfCollaborators
1..*
1..*
1..*
1..*
WorksWith 1..*
Collaborator
ComputerDevice
Software
Role
HasSimilarity4
1..*
1..*
1..*
Preference
*
1..*
Hardware
1..*
Sensor
Activity
1..* timeSlot:Integer
goal:String
sort:String
Skill
dexterityLevel:Integer
1..*
Availability
state:String
Stays
1..*
1..*
1
Profile
Modality
ContactMeans
PhysicalPlace
Calculates
CommonEnvironment
1..*
Has
Action
1..*
UserInterface
1..*
Workspace
1..*
Has
1..*
Setting
Has
PrivateWorkspace
SharedWorkspace
Runs
*
*
DistributedSetting
HybridSetting
PrivateObject
SharedObject
1..*
ColocalizedSetting
Link
1..*
GroupAwareness
CollaboratorBar
1..*
AbstractObject
Video
Text
Object
Runs
Audio Image
AdaptiveGroupwareApplication
+operation()
Comunication
ConcreteGroupwareApplication
+operation()
1..*
Notification
ImmediateForm
ContexOfUse
-application: AdaptiveGroupwareApplication
-collaborator: GroupOfCollaborators
-platform:SetOfPlatforms
-environment:CommonEnvironment
+operation()
PeriodicForm
ContexOfUse_1
+operation()
... ContexOfUse_n
+operation()
Single-user systems
Proposed extension
Cooperative systems
Figura 5.1: Contexto de uso de los sistemas colaborativos
coherentes (clase Action) sobre un objeto compartido (clase SharedObject) o privado (clase
PrivateObject) que tienen un objetivo común (atributo goal). La similaridad de actividades
132
es medida en términos del objeto compartido que está siendo manipulado por los colaboradores
y sus actividades actuales y potenciales (atributo sortActivity). La similaridad entre las
actividades de dos colaboradores puede tener alguno de los siguientes valores: muy similar,
similar, más o menos similar, poco similar, muy poco similar y no similar (cf. Mecanismo de
similaridad de actividades en la sección 5.2.1).
La figura 5.1 muestra que el medio de contacto de un colaborador (clase ContactMeans)
define el camino por el cual él quiere ser contactado en un momento dado, e.g., video-conferencia,
mensajerı́a instantánea, correo electrónico o voz IP. Ası́, cada colaborador puede ser contactado
por varios medios de comunicación dependiendo de:
1. el hardware y el software (clases Hardware y Software) disponible en su dispositivo actual
(clase ComputerDevice) i.e., uno de los que está utilizando para lograr su actividad en
curso, y
2. su estado de disponibilidad (clase Availability) o la similaridad entre sus actividades
actuales o potenciales y las de sus colegas que quieren contactarlo.
Los medios de contacto de un colaborador pueden ser establecidos automáticamente por el
sistema colaborativo (cf. Mecanismo medios de contacto en la sección 5.2.3) pero el usuario
tiene la posibilidad de modificarlos.
Un colaborador tiene a su disposición un espacio de trabajo (clase Workspace) que provee de
interfaces de usuario (clase UserInterface) para interactuar con sus colegas. Además, dicho espacio proporciona una área de trabajo privada (clase PrivateWorkspace), donde el colaborador
contribuye con sus aportaciones personales (clase PrivateObject). También, el colaborador
puede compartir con su grupo de colegas un espacio común (clase SharedWorkspace), el cual
provee consciencia de grupo (clase GroupAwareness) por medio de una barra de colaboradores
(clase CollaboratorBar). Dependiendo del rol actual del colaborador, su espacio de trabajo le
provee aplicaciones colaborativas para facilitar las actividades correspondientes a sus roles (cf.
Mecanismo para ocultar, sustituir o mostrar un componente en la sección 5.2.4).
Una aplicación colaborativa (clase AdaptiveGroupwareApplication) provee acciones
válidas (clase Action) para crear, modificar, anotar y borrar objetos compartidos (clase
SharedObject). Una aplicación colaborativa puede estar relacionada con otras por medio
de sus objetos compartidos (clase Link). Un objeto compartido es implementado siguiendo el
patrón de diseño Composite porque nuestro marco pretende soportar el dominio de aplicaciones
de edición colaborativa.
Cada instancia de una aplicación colaborativa es capaz de notificar (clase Notification)
a otras instancias, con la finalidad de que los colaboradores posean la información necesaria
para su actividad (cf. Figura 5.1). Dicha notificación puede ser enviada usando diferentes
modalidades (clase Modality), e.g., sonido, vibración o cuadros de texto, dependiendo tanto de
la actividad como de la ubicación fı́sica del colaborador. La comunicación (clase Comunication)
entre las instancias de una aplicación permite recuperar información nueva o almacenada.
Capı́tulo 5
133
Por medio de sus preferencias (clase Preference), cada colaborador puede expresar no solo
sus intereses en recibir información acerca de sus colegas y enviar información propia, sino
también la manera de ser notificado, i.e., el tipo de información, para/de quién, cuándo y
cómo. Particularmente, el envı́o y la recepción de información puede ser de dos formas:
1. instantáneo (clase ImmediateForm), la cual se refiere a notificar la información en el
momento justo en que es generada, y
2. periódica (clase PeriodicForm), la cual notifica en un tiempo predefinido.
El entorno común (clase CommonEnvironment) es donde la colaboración toma lugar, la cual
involucra bastantes variables contextuales, e.g., los lugares fı́sicos (clase PhysicalPlace) en
donde los colaboradores están interactuando. Dicha detección se logra mediante sensores (clase
Sensor) en hardware, e.g., sensores infrarrojos, o por software, e.g., reconocimiento de rostros.
Por lo tanto, tres posibles casos:
1. todos los colaboradores están distribuidos, i.e., cada uno esté localizado en un lugar
diferente (clase DistributedSetting);
2. todos los colaboradores están localizados en el mismo lugar (clase ColocalizedSetting);
3. forma mixta (clase HybridSetting), i.e., algunos colaboradores están colocalizados mientras otros están distribuidos.
Un despliegue multi-dispositivo y multi-usuario implica que cada colaborador puede no
solo tener la posibilidad para interactuar con otros colaboradores, si no también utilizar simultáneamente varios dispositivos para ejecutar sus actividades, e.g., cuando los colaboradores
están co-localizados (clase ColacalizedSetting), cada colaborador puede tener una computadora portátil (clase ComputerDevice), en donde su espacio de trabajo privado (clase
PrivateWorkspace) es desplegado, y un teléfono inteligente que actúa como control remoto
de un pizarrón electrónico, donde el espacio de trabajo compartido (clase SharedWorkspace)
puede ser visualizado por todos los colaboradores.
Dependiendo de la configuración del grupo algunos componentes pueden ser desplegados u
ocultados en la interfaz de usuario. Por ejemplo, si todos los colaboradores están co-localizados,
no resulta ventajoso que el sistema colaborativo muestre su disponibilidad y medios de contacto.
Algunos autores, como Haake et al [Haake et al., 2010], llaman “artefactos” a los documentos
de texto, imágenes, contenidos de chat y reportes. Nosotros nombramos a dichos artefactos
como “objeto abstracto” (clase AbstractObject) para referirnos a la información electrónica
que es utilizada, generada y compartida por los colaboradores. Dicha información extiende
los ejemplos anteriores como son: audios (clase Audio), videos (clase Video), imágenes (clase
Image), documentos de texto (clase Text) como son: manuales, reportes, artı́culos, información
relacionada con la comunicación, tales como conversaciones de texto provenientes de la mensajerı́a instantánea o por mensajes enviados desde un celular.
134
5.1.2
Diagrama de clases del vigilante
El componente de contexto de uso (clase ContexOfUse) está provisto de un vigilante (clase
Watcher), el cual es responsable de observar las cambios de contexto con el fin de ejecutar los
percutores de adaptación (clases Remodelation y Redistribution), la granularidad del estado
de recuperación (clase Recovery) y la granularidad de adaptación (clase Adaptation) ası́ como
de detectar cuándo se está manipulando un objeto compartido (clase Link) de manera implı́cita
o explicita (cf. Figura 5.2).
PrivateWorkspace
SharedWorkspace
Update
Update
MetaUI
+WithNegotiation()
+WithoutNegotiation()
+Plastic()
Remodelation
Redistribution
Recovery
Runs
Runs
Runs
Adaptation
Link
Runs
Watcher
Runs
Has
ContexOfUse
-application: AdaptiveGroupwareApplication
-collaborator: GroupOfCollaborators
-platform:SetOfPlatforms
-environment:CommonEnvironment
+operation()
Proposed extension
Figura 5.2: Diagrama de clases del observador
Varias de las clases que ejecuta la clase Watcher pueden ofrecer varios tipos de metainterfaz de usuario (clase MetaUI), los cuales corresponden a: meta-IU con negociación (método
WithNegotiation()), meta-IU sin negociación (método WithoutNegotiation()) y meta-IU
plástica (método Plastic()). Dicha meta-interfaz está acargo de informar los cambios que
deben ejecutarse en los espacios de trabajo compartido (clase SharedWorkspace) y privado
(clase PrivateWorkspace).
Como se mencionó en la sección 2.2 del capı́tulo 2, , la redistribución
[Vanderdonckt, et al., 2008] denota: “ La reasignación de los componentes de la interfaz
de usuario de una aplicación a diversos dispositivos de interacción. Los tipos de redistribución
son los siguientes: 1) de centralizada a centralizada, 2) de centralizada a distribuida, 3) de
distribuida a centralizada y 4) de distribuida a distribuida”.
Capı́tulo 5
135
La clase Redistribution tiene como finalidad redistribuir la interfaz de usuario de una
aplicación colaborativa en un conjunto de dispositivos, los cuales pueden pertenecer a un colaborador (clase Collaborator) o un grupo de colaboradores. La clase Watcher está encargada
de llamar a la clase Redistribution, cuando detecta alguno de los siguientes cambios:
• Cambio en la forma de trabajo:
– colocalizado (clase ColocalizedSetting), e.g., se reúne un grupo para trabajar, o
un colaborador se une al equipo colocalizado;
– distribuido (clase DistribuitedSetting), e.g., el grupo co-localizado se separa, pero
continúan trabajando sobre el mismo objeto;
– hı́brido (clase HybridSetting), e.g., sobre un mismo espacio compartido (clase
SharedWorkspace) trabajan colaboradores co-localizados y redistribuidos.
• Detección de varios dispositivos de cómputo (clase SetOfPlatforms):
– los colaboradores trabajan sobre un mismo espacio compartido (clase
SharedWorkspace) de manera co-localizada; los componentes de dicho espacio
serán redistribuidos sobre el conjunto de dispositivos (clase SetOfPlatforms) en
uso;
– los colaboradores trabajan sobre su espacio privado (clase PrivateSpace), ya sea
de manera distribuida y/o co-localizada, cada colaborador podrá aplicar la redistribución para configurar su propio espacio privado.
En la sección 2.2 del capı́tulo 2, la remodelación de la interfaz de usuario
[Vanderdonckt, et al., 2008, Coutaz and Calvary, 2008] denota: “Cualquier reconfiguración de
la interfaz de usuario de una aplicación que sea perceptible al usuario. La reconfiguración de
la interfaz de usuario resulta de la aplicación de una o más transformaciones sobre todos o
algunos de los componentes”.
La clase Remodelation permite ocultar, sustituir o agregar componentes en las interfaces
de usuario. Los componentes susceptibles a remodelar son los siguientes (cf. sección de los
escenarios 4.2):
• el espacio de trabajo:
– privado de un colaborador dependiendo sus roles (clase Rol), cuando este ingrese a
la sesión;
– compartido al detectar a un grupo de colaboradores trabajando colocalizadamente
(clase ColocalizedSetting) o distribuidamente (clase DistribuitedSetting);
• la información, e.g., ocultar la información al detectar una persona ajena al grupo de colaboradores o mostrar información dependiendo del lugar, de la fecha y de las necesidades
del colaborador;
136
• los medios de contacto y la disponibilidad del colaborador (clases Availability y
ContactMeans) dependiendo de quién sea el colaborador observado y observador;
La clase Watcher ejecuta la clase Remodelation al detectar algunos de los siguientes cambios
en el contexto:
• inicio de sesión por parte de un colaborador;
• detección del modo de trabajo (distribuido o co-localizado);
• detección de una persona ajena al grupo de trabajo, la cual está muy cerca del área de
despliegue de información;
• detección de la fecha y hora para enviar información relacionada a la actividad de un
colaborador;
• calculo de disponibilidad o medio de contacto.
Como se mencionó en la sección 2.4 del capı́tulo 2, la granularidad del estado de recuperación
caracteriza [Vanderdonckt, et al., 2008]:
“El esfuerzo de los usuarios que deben realizar para continuar su actividad después de ocurrida
la adaptación. Dicha granularidad aborda tres niveles: sesión, tarea y acción fı́sica”.
La clase Recovery tiene como finalidad almacenar el estado de los espacios de trabajo compartidos y/o privado (clases SharedWorkspace y PrivateWorkspace, respectivamente), los cuales
incluyen el trabajo en proceso. La clase Watcher ejecuta la clase Recovery antes de llevar a
cabo la adaptación al contexto por medio de la redistribución, la remodelación o la sugerencia
de seguir conversaciones mediante la detección de la utilización de un objeto compartido.
En la sección 2.3 del capı́tulo 2 se mencionó que la granularidad de los componentes de la
interfaz de usuario denota [Vanderdonckt, et al., 2008]:
“La unidad más pequeña de software que puede ser afectada por la remodelación y/o redistribución, las cuales pueden ser totales o parciales”.
La clase Adaptation tiene como finalidad adaptar la interfaz de usuario, cuando la clase
Watcher lanza en ejecución la remodelación y/o la redistribución.
Finalmente, la clase Link tiene como objetivo relacionar una aplicación con otra por medio
de sus objetos compartidos. La clase Watcher ejecutara la clase Link cuando detecta que dos
o más colaboradores hacen referencia a un mismo objeto compartido al mismo tiempo. Dicho
objeto está siendo manipulado por dos aplicaciones diferentes.
Capı́tulo 5
5.2
137
Mecanismos del marco XARE
El marco propuesto depende de varios mecanismos que proporcionan los cálculos necesarios
para la adaptación al contexto. Algunos de esos cálculos se llevan a cabo mediante reglas
difusas.
5.2.1
Mecanismo de similaridad de actividades
Este mecanismo es solicitado por los mecanismos de disponibilidad y el medio de contacto, ya
que dichos mecanismos lo requieren para hacer sus propios cálculos. La similaridad de actividades (cf. Figura 5.3) involucra a un colaborador observado y un observador. Los parámetros
necesarios para calcular la similaridad de actividades corresponden a: 1) las actividades potenciales y actuales que están siendo ejecutadas por dichos colaboradores, y 2) los objetos
compartidos que están procesando mediante sus acciones.
La similaridad entre las actividades de los colaboradores observado y observador pueden
tomar los siguientes valores:
1. muy similares, cuando ellos están llevando a cabo las mismas acciones sobre el mismo
objeto compartido;
2. similares, cuando los colaboradores están ejecutando las mismas acciones en diferentes
objetos que tienen cierta relación (e.g., una figura y el correspondiente párrafo que describe
esta);
3. más o menos similares, cuando ellos están ejecutando las mismas acciones en diferentes
objetos no relacionados (e.g., modificación de diferentes secciones);
4. poco similares, cuando dos colaboradores están ejecutando diferentes acciones sobre
objetos relacionados;
5. muy poco similares, cuando ellos están ejecutando diferentes acciones sobre diferentes
objetos;
6. no similares en cualquier otro caso.
En la tabla 5.1 se ejemplifica la forma de asignar los grados de similaridad entre las actividades
entre el colaborador un y las de sus colegas u1 , u2 , u3 , u4 , u5 y u6 toma en cuenta las acciones
actuales que están llevando acabo aquellos colaboradores, además de considerar los objetos que
están manipulando por medio de tales acciones. También se está considerando las acciones
y los objetos que son potencialmente accesibles por el colaborador un . De está forma, el
colaborador un tiene actividades muy similares y similares a las de los colaboradores u1 y u2
138
GrupoDeColaboradores
tiene
Acción:
acción_a
Objeto:
objeto_b
Objeto:
Objeto:
objeto_a
objeto_a
Collaborador:
observador
tiene
tiene
tiene
Actividad:
actividad_a
tiene
FechaLímite:
fechaLímite
Disponibilidad:
disponibilidad
)
ar(
cre
Preferencias:
preferencias
evaluar
Collaborador:
observador
tiene
tiene
Action:
action_b
Actividad:
tiene
actividad_b
ac
tiv
ida
d_
actividad_b
a
d
ida
lar do y
i
sim serva dor)
(ob serva
ob
Mecanismo:
Similaridad
s
(o imil
ob bser arid
se va ad
rv do
ad y
or
)
disponibilidad del usuario
observado
Mecanismo:
Disponibilidad
tiene
Mecanimo:
Medio de contacto
preferencias del usuario observado
características
ConjuntoDePlataformas
características
tiene
Dispositivo:
dispositivo_a
tiene
Hardware:
hardware
Software:
software
tiene
Dispositivo:
dispositivo_b
tiene
Figura 5.3: Mecanismo para determinar entre dos colaboradores su similaridad de actvidades,
la disponibilidad y los medios de contacto
respectivamente durante una sesión de trabajo donde los colaboradores u1 y un están concurrentemente modificando el objeto compartido o, mientras que el colaborador u2 está modificado
el objeto compartido p, el cual está relacionado con el objeto o.
Sin embargo, la situación previamente mencionada puede ser completamente diferente en una
sesión subsecuente o incluso en la misma sesión, debido al carácter dinámico del trabajo cooperativo. Por ejemplo, si el colaborador un empieza a hacer anotaciones en el objeto compartido
q, el cual no está relacionado con el objeto o ni con el objeto p, mientras los colaboradores u1
y u2 están haciendo las actividades mencionadas, las actividades del colaborador un pueden no
ser similares a algunas de los colaboradores u1 y u2 .
Capı́tulo 5
139
Actividades
un está modificando el
objeto o
un está haciendo anotaciones sobre el objeto
q, el cual no está relacionado con p
u1 está modificando el obMuy similares
jeto o
Potencialmente no similares
u2 está modificando el objeto p, el cual está rela- Similares
cionado con o
Potencialmente no similares
u3 está modificando el objeto q, el cual no está rela- Más o menos similares
cionado con o
Potencialmente
similares
u4 está haciendo anotaPoco similares
cioens sobre el objeto o
Potencialmente más o
menos similares
u5 está leyendo el objeto p
Muy poco similar
Potencialmente no similar
u6 está leyendo el objeto q
No similares
Potencialmente
similares
poco
poco
Tabla 5.1: Similaridad entre las actividades de dos colaboradores
Las clases utilizadas en este mecanismo corresponden a: Activity y Action. La primera
clase permite obtener el conjunto de actividades asociados a ambos colaboradores (observado
y observador), ası́ como hacer el cálculo de la similaridad de actividades mediante el método
HasSimilarity; mientras que la clase Action permite identificar sobre qué objeto compartido
están trabajando dichos colaboradores en ese momento para inferir la actividad en curso.
5.2.2
Mecanismo de disponibilidad de un colaborador
Este mecanismo es responsable de determinar la disponibilidad de los colaboradores, cuyo
valor varia de un observador a otro. Un colaborador puede ser percibido como presente o
ausente durante una sesión de trabajo. En caso de que el colaborador observado esté presente,
el observador puede percibir subestados, cuyo objetivo es proveer más detalle acerca de la
disponibilidad del colaborador observado. Ası́, cuatro subestados son considerados por este
140
mecanismo:
1. ocupado: posibilita al colaborador observado a informar que no quiere ser interrumpido;
2. accesible: permite al colaborador observado indicar que, aún si él está ocupado, puede
ser interrumpido si es necesario y tan pronto como él pueda responderá;
3. alcanzable si es posible: el colaborador observado admite que puede ser interrumpido, pero no asegura una rápida respuesta;
4. disponible: permite al colaborador observado ser contactado en cualquier momento.
Al igual que la similaridad de actividades, la disponibilidad se calcula tomando en cuenta la
información siguiente del colaborador observado y del observador (cf. Figura 5.3):
1. la similaridad entre las actividades (potencial o actual) del colaborador observado y el
observador, y
2. la fecha lı́mite de la actual actividad (e.g., distante o cercana) del colaborador observado.
En caso de que la disponibilidad haya sido establecida manualmente por el colaborador observado, este mecanismo tiene que considera las preferencias establecidas por él.
La tabla 5.2 muestra algunos ejemplos de los subestados de disponibilidad de un colaborador observado, tal como estos son percibidos por un observador de acuerdo a las condiciones
previas. Cuando el colaborador observado y el observador están ejecutando actividades muy
similares o similares, el observador puede percibir la disponibilidad del colaborador observado
como accesible, aún si la fecha lı́mite de la actividad de esté último observado es cercana o
distante. En está situación, el mecanismo favorece la posibilidad de mantener comunicación
con el colaborador observado, desde el punto de vista de actividades similares.
Por otro lado, si los colaboradores están ejecutando actividades más o menos similares o
poco similares, el observador puede percibir la disponibilidad del colaborador observado como
alcanzable si es posible, cuando la fecha lı́mite de la actividad de este último es cercana;
de otra manera su disponibilidad será accesible cuando la fecha lı́mite de la actividad sea
distante. En el caso de aquellos colaboradores estén ejecutando actividades muy poco similares
o diferentes, pero una de las actividades potenciales del observador es similar o muy poco
similar a la actividad actual del observado, el observador puede percibir la disponibilidad del
observado como alcanzable si es posible, sin importar cuando se termina la actividad
del colaborador observado. En estas situaciones, el mecanismo facilita el contacto entre los
colaboradores, aunque en diferentes grados.
Cuando las actividades actuales tanto del colaborador observado como del observador son
muy poco similares o no similares, pero sus actividades potenciales son poco similares
Capı́tulo 5
141
Fecha lı́mite
Disponibilidad del colaborador observado
Cercano
La actividad actual del observador es similar o muy
Accesible
similar a la del colaborador observado
La actividad actual del observador es más o menos
similar o poco similar a la del colaborador observado
Accesible
si es posible
...
Distante
Accesible
Accesible
La actividad actual del observador es muy poco
Alcanzable
similar o no es similar a la del colaborador obsersi es posivado, pero una de sus actividades potenciales es similar
ble
o muy similar
Alcanzable
si es posible
La actividad actual del observador es muy poco
similar o no es similar a la del colaborador obserOcupado
vado, pero una de sus actividades potenciales es más o
menos similar o poco similar
Alcanzable
si es posible
La actividad actual y las potenciales del colaborador observador son muy poco similares o no son
Ocupado
similares a la actividad actual del colaborador observado
Ocupado
Tabla 5.2: Estado de disponibilidad del colaborador observado respecto a un colaborador observador
o más o menos similares en un momento dado, el mecanismo solo facilita el contacto cuando
la fecha lı́mite de la actividad del observador es distante. De otra manera, el colaborador
observador percibe al observado como ocupado. Finalmente, si el colaborador involucrado no
tiene en común actividades actuales o potenciales, el contacto es imposible. Sin embargo,
esté mecanismo puede ser configurado por cada colaborador para proveer flexibilidad para
ser contactado. Por ejemplo, este mecanismo permite al observador tener contacto con el
colaborador observado, cuando la fecha lı́mite de la actividad actual de este último sea distante.
Esta situación es razonable, ya que ese colaborador observador está trabajando en el mismo
proyecto.
Aún si los subestados de la disponibilidad están determinados por el mecanismo propuesto,
el colaborador observado puede modificarlos cuando él lo requiera.
142
En consecuencia, este mecanismo usa las clases: Availability y Activity. El mecanismo
de disponibilidad forma parte de la primera clase, Availability. La clase Activity proporciona la similaridad entre las actividades de los colaboradores involucrados, ası́ como el tiempo
lı́mite de la actividad en curso del colaborador observado (cf. atributo timeSlot de la clase
Availability de la figura 5.1).
5.2.3
Mecanismo de medios de contacto
Los medios de contacto de un colaborador se refieren a las formas en que otros colaboradores
pueden contactarlo, e.g., correo electrónico, video conferencia y voz. Aunque cada colaborador
tiene la libertad de determinar su preferencia por algunos medios de contacto, existe un cálculo
automático para proveer dichos medios de manera automática. Para dicho cálculo se requieren
varios parámetros (cf. Figura 5.3), los cuales son los siguientes:
1. los subestados de la disponibilidad de los colaboradores (disponibilidad de un colaborador), la cual fue calculada a partir de las actividades que ejecutan sobre un objeto
(similaridad de actividades);
2. el medio de contacto preferido del colaborador observado,
3. las caracterı́sticas de hardware y software de los dispositivos de los colaboradores involucrados.
Considerando los parámetros de entrada del mecanismo de medios de contacto (disponibilidad, preferencias acerca de los medios de contacto y caracterı́sticas de los dispositivos) se
muestra un ejemplo de como establecer los medios de contacto:
• video-conferencia, voz y mensajerı́a instantánea por colegas cuya actividad actual o potencial es muy similar o similar;
• anotaciones privadas sobre el texto de colegas cuya actividad actual o potencial es poco
similar a su actual o potencial actividad, y
• correo electrónico de otra manera.
Para todos los medios de contacto, se debe verificar que ambos colaboradores tengan tanto el
hardware como el software que soporte dicho servicio; de otra manera, el medio de comunicaión
no estará disponible.
Las clases involucradas en este mecanismo corresponde a: ContactMeans, Availability,
Hardware y Software. Mediante las dos últimas clases, Hardware y Software, se obtienen las
caracterı́sticas de los dispositivos que usan ambos colaboradores, el observado y el observador.
Capı́tulo 5
143
La clase Availability permite conocer la disponibilidad del colaborador observado. Finalmente, la clase ContactMeans contiene una lista de medios de contacto asociados al usuario
observador. Dicha lista de medios de contacto es visualizada por el observador.
5.2.4
Mecanismo de ocultar, sustituir y mostrar componentes
El mecanismo de ocultar, sustituir y mostrar componentes modifica la visibilidad de los componentes, e.g., dependiendo del rol del colaborador se ocultan los iconos de acceso directo a las
aplicaciones o dependiendo del espacio libre en el disco local de un dispositivo se puede ofrecer
guardar información en otro dispositivo. En el escenario 4.4 se explica más a detalle los posibles
usos de este mecanismo.
Este mecanismo (cf. Figura 5.4) tiene dos parámetros de entrada, los cuales corresponden a
1. el rol del colaborador, y
2. el conjunto de dispositivos disponibles, los cuales incluyen los que pertenecen a los colaboradores participantes en la sesión o servidores.
Para explicar mejor el mecanismo de la figura 5.4, supongamos un colaborador (A) que tiene
asociado un rol, dicho colaborador ingresa a su espacio de trabajo mediante un conjunto de
dispositivos (A). El mecanismo debe ocultar o mostrar un componente o un conjunto de componentes dependiendo los posibles roles que puede desempeñar el colaborador, ası́ como el conjunto
de dispositivo que está usando dicho colaborador (dispositivo A). En el caso de componentes
que representen una funcionalidad, e.g., ı́cono de guardar o imprimir; el mecanismo debe verificar si es posible ofrecer esas funcionalidades o requiera usar otros dispositivos (B), los cuales
no pertenecen al colaborador (A). Los componentes susceptibles a ser modificados pertenecen
al espacio de trabajo del colaborador (A).
Las clases involucradas en este mecanismo corresponden: Role, ComputerDevice y
Workspace. La clase Role proveerá todos los roles asignados a dicho colaborador, mientras
que la clase ComputerDevice proporcionará las caracterı́sticas de hardware y software de los
dispositivos en uso del colaborador, y además, cuando sea necesario, proveerá las caracterı́sticas
de los dispositivos que pueda usar el colaborador. La clase Workspace reflejará la modificación
de los componentes, ya sea que modifique el espacio de trabajo o la funcionalidades que ofrecen
las aplicaciones, e.g., los iconos ofrecidos por una aplicación pueden ser ocultados ya que no
están relacionados al rol del colaborador.
144
tiene
tiene
Colaborador:
colaborador_a
Rol:
rol
rolActual
tiene
EntornoComún
EspacioDeTrabajo:
espacioDeTrabajo
mod
ifica
rCom
pone
nte()
tiene
Mecanismo:
Ocultar/Mostrar
AplicacionesCooperativas:
aplicacionesCooperativas modificarComponente()
Dispositivos personales
Dispositivos
opcionales
ConjuntoDePlataformas
tiene
Dispositivo: tiene Sofware:
software
dispositivo_a
Hardware: tiene
hardware
Dispositivo:
dispositivo_b
tiene
Figura 5.4: Mecanismo para ocultar, sustituir o mostrar funcionalidades y/o componentes
5.2.5
Mecanismo de creación de hiperligas entre los objetos compartidos
El mecanismo de creación de hiperligas permite crear referencias de objetos compartidos entre
aplicaciones, con la finalidad de que dichos objeto no pierda su contexto.
El mecanismo Deixis (cf. Figura 5.5), que provee la mensajerı́a instantánea, permite a los
colaboradores crear hiperligas entre una palabra clave y un objeto compartido que pertenece al
editor colaborativo. Gracias a la funcionalidad ofrecida por este mecanismo, los colaboradores
no necesitan copiar los párrafos referenciados desde el editor colaborativo hacia la mensajerı́a
instantánea para referenciar dicho párrafo.
El mecanismo de hiperligas tiene dos parámetros de entrada, los cuales son:
1. la selección de un objeto compartido desde el editor colaborativo. Dicho objeto se puede
referir a: un tı́tulo, un párrafo, una frase, una palabra, una referencia, una figura o una
Capı́tulo 5
145
Colaborador:
colaborador_a
tiene
Rol:
rol
tiene
EntornoComún
EspacioDeTrabajo:
espacioDeTrabajo
tiene
mensajeríaInstantánea
tiene
e
Mecanismo:
Deixis
tiene
ObjetoCompartido:
palabraDeíctica
editorColaborativo
tien
a
eític
pár
ra d
b
pala
tiene
rafo
tien
ObjetoCompartido:
párrafo
e
tien
e
ReferenciaDeítica:
referenciaDeíctica
Figura 5.5: Creación de hiperligas desde la mensajerı́a instantánea
sección, y
2. la palabra deı́ctica seleccionada desde la opción Deixis. Las palabras deı́cticas pueden
corresponder a alguna de las siguientes: this figure, the next section, this paragraph, those
references o here.
En la figura 5.5 se puede observar a un colaborador (colaborador) que está trabajando en
su espacio de trabajo (espacioDeTrabajo), en donde él está usando la mensajerı́a instantánea
(mensajerı́aInstantánea) y el editor colaborativo (editorColaborativo). En este caso, el colaborador crea una hiperliga entre una palabra deı́ctica (palabraDeı́ctica) y un párrafo (párrafo)
mediante el mecanismo Deixis.
Por otro lado, cuando el colaborador de clic sobre la referencia recibida, la aplicación de
mensajerı́a instantánea debe mostrar el objeto referenciado a la mitad del área des despliegue
del editor. En el caso de que el objeto referenciado sea un texto, este debe cambiar de color;
en cambio, si el objeto referenciado es una imagen, esta debe estar encerrada en un recuadro.
Además de encerrar la imagen referencia en un recuadro, el espacio de trabajo debe ofrecer
146
la opción de crear una copia en el pizarrón multi-usuario. Dicha copia contiene un id interno
dentro del documento origen, ası́ como el nombre y la ubicación de dicho documento. Las
modificaciones realizadas desde el pizarrón serán reflejadas automáticamente en el editor de
texto.
Las clases involucradas en este mecanismo corresponden a: Link y SharedObject. Las clase
Link contiene el mecanismo Deixis, mientras que la clase SharedObject contiene todos los
posibles objetos susceptibles a ser referenciados.
5.2.6
Mecanismo de proximidad lógica
La proximidad lógica entre los colaboradores es medida en términos de la relativa cercanı́a entre
los objetos compartidos que se están manipulando en el espacio de trabajo compartido.
En una sesión colaborativa, los colaboradores pueden estar creando, modificando, visualizando y/o anotando en los objetos compartidos que pertenecen a un documento de texto o
de imagen. Ambos documentos siguen una estructura de árbol, la cual permite mostrar la
granularidad de dichos objetos (cf. Figura 5.6).
Los objetos compartidos tales como documentos de texto o proyectos de imágenes pueden
ser representados mediante árboles, cuyo nodo raı́z es el nombre del documento (el contenedor
de texto e imágenes) o el proyecto (el contenedor de imágenes) en cuestión.
Mediante la figura 5.6a podemos observar que la granularidad de documentos de texto que
va desde el documento completo hasta el nivel palabra. La estructura de la figura 5.6a muestra
un documento de texto, cuyo nombre es Di , el cual tiene secciones (S) que pueden contener:
párrafos (P ), imágenes (I) o subsecciones (U). A su vez, dichas subsecciones también pueden
alojar: párrafos e imágenes. Los párrafos se componen de palabras (A).
En el caso de las imágenes, la granularidad va desde el nivel proyecto hasta nivel de figuras,
las cuales puede ser una lı́nea, un cı́rculo, un rectángulo y un cuadrado. La figura 5.6b muestra
un proyecto de imágenes vectoriales, cuyo nombre es (Pi ), el cual contiene hojas (H) que sirven
de lienzos para el dibujo. Dichas hojas contienen imágenes (I) que están compuestas por figuras
(F ) básicas.
En este mecanismo se propone definir grados de proximidad lógica en el espacio de trabajo
compartido de la siguiente manera:
1. muy cercanos, cuando los colaboradores están accediendo al mismo objeto compartido,
a pesar de sus respectivos tipos de acceso (e.g., leer, escribir o anotar);
2. más o menos cercano, cuando los colaboradores están procesando diferentes objetos
compartidos (e.g., subsecciones), las cuales tienen el mismo padre (e.g., una sección);
Capı́tulo 5
147
Di
...
DiS1
DiS1Un... DiS1Pn ...
DiS1UnIn
DiS1UnPn
DiS1In
DiSnUn ...
DiS1PnAn
DiS1UnPnAn
DiSn
DiSnPn ...
DiSnIn
DiSnUnPn DiSnUnIn DiSnPnAn
DiSnUnPnAn
Documento(D)
Sección (S)
Subsección (U)
Párrafo (P)
Palabra (A)
Imagen (I)
i-ésimo objeto compartido
n-ésimo objeto compartido
(a) Visualización de un documento de texto
Pi
PnHn
PiHi ...
PiH1 ...
PiH1I1...
PiH1In
PiHiI1...
PiHiIn
PiH1I1Fn
PiH1InFn
PiHiI1Fn
PiHiInFn
Proyecto (Di)
Hoja (H)
Imagen (I)
PiHnI1...
PiHnIn
Figura (F)
i-ésimo objeto compartido
n-ésimo objeto compartido
(b) Visualización de un proyecto de imágenes
Figura 5.6: Visualización de documentos en forma de árbol
3. potencialmente más cercano cuando un colaborador trabaja sobre un objeto compartido (e.g., subsecciones), el cual es potencial para otro colaborador, cuyos objetos comparten el mismo padre (e.g., una sección);
4. potencialmente remoto, cuando los colaboradores están accediendo a diferentes objetos
compartidos que no comparten el mismo padre, pero alguno de sus objetos potenciales
(e.g., subsecciones) tienen el mismo padre (e.g., una sección);
5. remoto de otra manera.
La tabla 5.3 ilustra los diferentes grados de proximidad lógica entre el colaborador un y sus
colegas u1 , u2 y u3 . En este mecanismo (cf. Figura 5.7), los parámetros de entrada corresponden
148
a: 1) los objetos actuales, los cuales ellos están accediendo, y 2) los objetos potenciales que son
los objetos que están al alcance de los colaborador (en este ejemplo, el colaborador un ). Tanto el
objeto potencial como el actual pueden ser determinados desde la actividad actual y potencial
del colaborador, respectivamente. Ası́, aunque el colaborador un y u3 estén remotamente en el
espacio compartido al manipular los objetos o y q respectivamente, la posibilidad de acceder
otros objetos compartidos (e.g., un puede también manipular q) permitiendo al colaborador un
estar potencialmente muy cercano al colaborador u3 , y lejos de los colaboradores u1 y u2 en el
espacio compartido.
Proximidad lógica
Objeto actual o del componente c de un
Objeto potencial q del
componente d de un
Objeto actual o del compoMuy cercano
nente c de u1
Potencialmente remoto
Objeto actual p del compoMas o menos cerca
nente c, p 6= o, de u2
Potencialmente remoto
Objeto actual q del compoRemoto
nente d, d 6= c, de u2
Potencialmente mas cercano
Tabla 5.3: Proximidad lógica entre dos colaboradores dentro del espacio compartido
Las clase involucradas corresponden a: AbstractObject, Activity, Action y SharedObject.
La clase SharedObject contiene los objetos compartidos, a los cuales se les puede hacer un
cálculo de proximidad lógica. La clase AbstractObject permite tener la estructura de árbol
para los documentos de texto y de imágenes, ası́ como hacer el cálculo de dicha proximidad.
En el caso de los objetos abstractos referentes tanto al audio como al video, ambos serán
tratados como un solo objeto compartido dependiendo de las necesidades del proyecto. La clase
Activity proporcionará los objetos potenciales; mientras que la clase Action proporcionará el
objeto actual.
5.2.7
Mecanismo tipo de trabajo
El mecanismo tipo de trabajo (DetecciónTipoDeTrabajo) se encarga de determinar como
está trabajando un grupo de colaboradores, i,e., co-localizadamente, distribuidamente o
hı́bridamente.
Los parámetros necesarios en este mecanismo son los siguientes:
1. el grado de la proximidad lógica (cf. Mecanismo proximidad lógica 5.2.6);
Capı́tulo 5
149
2. el tiempo (hora y fecha) permite registrar el momento en que entra y sale cada colaborador
de un lugar especı́fico;
3. la ubicación de cada colaborador puede ser obtenida por hardware (e.g., sensores infrarrojos, sensores de Identificación por Radio-Frecuencia (RFID)) o software (e.g., detección
de rostros o Near Field Communication (NFC)). La ubicación puede ser obtenida cuando
el mecanismo DetecciónTipoDeTrabajo lo requiera o puede ser obtenida desde una base
de datos. Esto depende de la forma en que se detecta al usuario, e.g., los sensores ubicados
en la entrada de cada habitación registran la presencia de cada colaborador al momento
que entra a la habitación, dicho registro se hace sobre una base de datos.
En la figura 5.7 se muestra dos colaboradores (A y B), los cuales tienen asociada una ubicación
fı́sica (mediante la instancia de la ubicaciónFı́sica). La ubicación fı́sica permitirá conocer
el lugar de trabajo, mientras que el mecanismo de proximidad lógica identifica si existe alguna
relación entre los objetos compartidos actuales. Tanto la ubicación fı́sica como la proximidad
lógica permitirán identificar si los colaboradores trabajan de manera co-localizada, distribuida o
hı́brida. Una vez que se determina el tipo de trabajo se pueden hacer adaptaciones contextuales,
e.g., desplegar en ciertos dispositivos el espacio público y en otros el espacio privado o proveer
los ı́conos relacionados entorno al rol de los colaboradores.
Colaborador:
colaborador_A
tiene
Actividad:
actividad_A
actividades
Actividad:
actividad_B
tiene
Colaborador:
colaborador_B
actividades
tiene
EntornoComún
Mecanismo:
ProximidadLógica
tiene
Ubicación:
ubicaciónFísica
Grado de
proximidad
lógica
Ubic
ación
ción
Mecanismo:
DetecciónTipoTrabajo
Ubica
Ubicación:
ubicaciónFísica
Figura 5.7: Mecanismo de tipos de trabajo
150
5.3
Marco XARE
El marco XARE (conteXt-Aware groupwaRE) pretende orientar a los diseñadores en la creación
de aplicaciones colaborativas adaptativas al contexto de uso, considerando la remodelación y
la redistribución.
5.3.1
Capas del marco
El marco propuesto se compone de tres capas: detección, adaptación y espacio de trabajo. La
capa detección, que se encuentra en la parte inferior del marco, es responsable de reconocer
cambios en las variables contextuales, por medio de perceptores lógicos y fı́sicos.
La capa adaptación analiza la información obtenida por la capa detección para determinar si
los nuevos cambios en el contexto de uso requieren o no la adaptación de los espacios de trabajo
públicos o privados de una aplicación colaborativa. Cuando la capa adaptación considere la
adaptación al cambio contextual, esta capa informa a la capa espacio de trabajo como debe ser
implementada la adaptación (cf. Figura 5.8).
La capa superior, espacio de trabajo, es responsable de llevar a cabo la serie de preguntas
hechas por la capa adaptación.
La capa detección se encarga de detectar de manera automática algún cambio ocurrido en
el contexto, i.e., las cosas relevantes externas al sistema y los eventos ocurridos en la sistema.
Esta capa se compone de dos tipos de perceptores
1. Perceptores lógicos: son mecanismos de software que pueden identificar cambios en las
siguientes variables contextuales lógicas:
• Variable dispositivos: representa las plataformas actuales de interacción de cada colaborador; dichas plataformas ejecutan las aplicaciones colaborativas. Mediante esta
variable es posible obtener las caracterı́sticas de hardware y software de los dispositivos para adaptar las aplicaciones colaborativas al elemento conjunto de plataformas
del contexto de uso.
• Variable disponibilidad: denota la disponibilidad de cada colaborador, el cual puede
ser definida manualmente por el colaborador o de manera automática, al ser inferida
por la aplicación colaborativa (cf. sección 5.2.2). Como se mencionó en la sección
5.1, esta variable puede tomar el valor presente o ausente; pero si el colaborador esta
presente, él puede estar ocupado, accesible, alcanzable si es posible y disponible.
• Variable actividad actual: representa la actividad en curso de cada colaborador, la
cual puede ser inferida automáticamente por una aplicación colaborativa con base
en las acciones ejecutadas por el colaborador sobre los objetos compartidos.
• Variable proximidad lógica: denota la cercanı́a entre un colaborador y sus colegas
dentro del espacio de trabajo (cf. sección 5.2.6).
Capı́tulo 5
151
Capa de Espacio de Trabajo
ifica
Meta- Interfaz de usuario
mod
Con
negociación
mod
Sin
negociación
Meta-IU
plástica
Capa de Adaptación
Reglas de
adaptación
ifica ET compartido
Medios de adaptación
define
Remodelación
define
defi
ne
Granularidad de
adaptación
ET privado
Redistribución
Granularidad del estado
de recuperación
Capa de Detección
Perceptores lógicos
Dispositivos
Disponibilidad
Actividad
actual
Proximidad
lógica
Interfaces
de usuario
Perceptores físicos
Ubicación del
colaborador
Proximidad
física
Información
contextual
Figura 5.8: Capas del marco XARE
2. Perceptores fı́sicos: se refieren a sensores que son capaces de reconocer cambios en la
siguientes variables contextuales fı́sicas:
• Variable configuración colaborativa de un grupo trabajando: Estos incluyen sensores,
tales como RFID (Radio Frequency IDentification) o por la tecnologı́a de Bluetooth,
que permiten descubrir la entrada o salida de cada colaborador en un lugar especı́fico,
para determinar si un grupo esta trabajando de manera co-localizada o distribuida.
• Variable proximidad fı́sica: Este denota la cercanı́a entre el dispositivo de un colaborador y de su colega. Por medio de esta variable es posible que dos colaboradores
acoplen sus tabletas para crear un espacio publico a partir de dos espacios privados, como en Connectables [Tandler et al., 2001], o extender un espacio de trabajo
compartido.
La capa adaptación está compuesta de los siguientes módulos:
152
1. Reglas de adaptación: con base en la detección de cambios en el contexto de uso, este
módulo analiza si la aplicación colaborativa en cuestión necesita ser adaptada o no. En
caso de que la adaptación es requerida, este módulo también especifica el tipo de técnica
necesarias para adaptar la aplicación colaborativa, ası́ como la granularidad de adaptación
y recuperación.
2. Medios de adaptación: se refiere al resultado del proceso de adaptación percibido por los
colaboradores en la Interfaz de Usuario (IU). Ası́, el proceso de adaptación puede usar
varias de las siguientes técnicas:
• Redistribución: consiste en la reorganización de los componentes de la IU a diversos
dispositivos de interacción. Cuatro tipos de redistribución han sido identificados
[Calvary et al., 2006]: a) de centralizada a centralizada, cuyo objetivo es conservar
el estado centralizado de una IU, e.g., migración total de una PC a una PDA; b)
de centralizada a distribuida, la cual desmiembra una IU en varias plataformas, e.g.,
repartición entre una PC y un PDA; c) de distribuida a centralizada: reconcentra
una IU en una sola plataforma; y d) de distribuida a distribuida, la cual cambia el
estado de la distribución.
• Remodelación: involucra la reconfiguración de la IU por medio de inserción,
supresión, substitución y reorganización de todos o algunos componentes de la IU.
Las transformaciones se aplica a diferentes niveles de abstracción: intra-modal, intermodal y multi-modal. La remodelación intra-modal ocurre cuando los componentes
fuentes son redefinidos en la misma modalidad, e.g., si la IU fuente es multi-modal,
entonces la IU objetivo también será multimodal, i.e., la remodelación intra-modal no
provoca ninguna pérdida en las modalidades establecidas. En este caso, la modalidad se preserva, e.g., de gráfico a gráfico. La remodelación inter-modal redefine
una modalidad diferente, ya que los componentes fuentes de la IU que necesitan
ser remodelados se ven afectados al perder o aumentar una modalidad. Ası́, una IU
multi-modal puede ser convertida en una IU mono-modal o de manera inversa. La remodelación multi-modal permite la combinación de transformaciones (intra- e ı́ntermodal), e.g., la herramienta TERESA [Paterno et. al., 2008] utiliza la modalidad
gráfica y vocal.
3. Granularidad de adaptación: denota la unidad más pequeña de la IU que puede
ser remodelada y/o redistribuida.
Tres granos de adaptación son identificados
[Vanderdonckt, et al., 2008]: a) total, el cual implica modificar completamente la IU;
b) espacio de trabajo, el cual se refiere a un espacio lógico que apoya la ejecución de un
conjunto de tareas lógicamente conectadas, e.g., una ventana de impresión; c) interactor,
el cual representa la unidad más pequeña que soporta una tarea, e.g., el botón “Save”
de un editor. Otro grano, llamado Pixel, se refiere a cualquier componente de la IU que
puede ser dividido en múltiples superficies; sin embargo, este grano de adaptación sólo
concierne a la técnica de redistribución.
4. Granularidad del estado de recuperación: representa el esfuerzo de los usuarios que deben
Capı́tulo 5
153
realizar para continuar su actividad después de ocurrida la adaptación de la IU. Tres
granos de recuperación son considerados [Vanderdonckt, et al., 2008]: nivel sesión, el
cual fuerza a los usuario a reiniciar, perdiendo el efecto de todas sus acciones ejecutadas;
nivel tarea, el cual asegura que todas las tareas terminadas son persistentes, excepto la
tarea actual interrumpida; nivel de acción fı́sica, la cual asume que el usuario no pierde
el efecto de ninguna acción.
La capa espacio de trabajo está compuesto de los siguientes módulos (cf. Figura 5.8):
1. Meta-interfaz de usuario (meta-IU): consiste en un conjunto de funciones, cuyo objetivo
es evaluar y controlar de una aplicación colaborativo. Coutaz y Calvary identifican tres
tipos de meta-interfaz de usuario [Coutaz and Calvary, 2008]: a) meta-IU sin negociación,
la cual permite observar el estado del proceso de adaptación, pero no permite que el
usuario intervenga; meta-IU con negociación, la cual es recomendable cuando la meta-IU
no puede tomar decisiones entre las múltiples formas de adaptación, o cuando el usuario
debe controlar el resultado del proceso; y c) meta-IU plástica, la cual está diseñada para
instanciar una meta-IU cuando la aplicación es lanzada en ejecución.
2. Espacio de trabajo privado: representa el espacio personal donde un colaborador produce
sus propias contribuciones, las cuales no son visibles a sus colegas.
3. Espacio de trabajo compartido: simboliza el espacio común donde los miembros de un
grupo coopera al hacer sus contribuciones perceptibles a todos los miembros del grupo
colaborativo, cuando la estratificación no existe o, de otra manera, por algunos miembros.
El almacenamiento que usa el marco XARE está compuesto de dos repositorios (cf. Figura
5.8):
1. El repositorio de información contextual principalmente administra y almacena información estable, e.g., preferencias de los colaboradores, perfiles, ası́ como tareas y actividades potenciales. Cuando el dispositivo de un colaborador no tiene suficientes capacidades para almacenar información dinámica (e.g., la ubicación actual del colaborador, los
objetos compartidos en uso y las caracterı́sticas de los dispositivos actuales), esta base de
datos está encargada de almacenar dicha información.
2. Para dispositivos con poca capacidad de almacenamiento, el repositorio de interfaces de
usuario almacena y administra información necesario para desplegar las interfaces de
usuario (e.g., diferentes vistas de interacción y espacios de trabajo, frecuencia de uso de
algunos interactores) y el estado de recuperación (e.g., todas las acciones ejecutadas o
tareas terminadas).
154
5.4
Conclusiones
El marco propuesto puede servir como referencia para crear aplicaciones colaborativas plásticas,
ya que es posible observar las dependencias que existen entre las clases y los elementos del
contexto de uso. Dicho marco considera la mayorı́a de los escenarios propuestos en el capı́tulo
4, en especifico aborda los escenarios implementados.
En la tabla 5.4 se proveen mecanismos para implementar cuatro de los ocho escenarios presentados. El escenario “mejoramiento del trabajo colaborativo”, el cual se refiere a crear ligas
entre una palabra clave de la mensajerı́a instantánea y un objeto compartido de un editor colaborativo mediante la función de deixis, puede ser implementado mediante el mecanismo de
“creación de hiperligas entre los objetos compartidos”. Este mecanismo permite crear ligas no
solo desde una aplicación de mensajerı́a instantánea sino desde cualquier otra aplicación. Esto
se puede lograr gracias a que la clase Link es parte del Desktop.
Escenario
Mecanismos
1. Mejoramiento del trabajo colaborativo
5.2.5. Creación de hiperligas entre objetos compartidos
2. Remodelación de componentes
de la interfaz de usuario
5.2.4. Ocultar, sustituir o mostrar
componentes
3. Redistribución del sistema colaborativo en función de la configuración del grupo
5.2.7. Ubicación fı́sica y
5.2.6. Proximidad lógica
4. Adaptar los medios de contacto y disponibilidad
5.2.1. Similaridad de actividades,
5.2.2. Disponibilidad y
5.2.3. Medio de contacto
Tabla 5.4: Sugerencia para llevar a cabo cuatro escenarios
En el caso del escenario “remodelación de componentes de la interfaz de usuario” que permite la modificación de componentes mediante ocultación, agregación o sustitución puede ser
implementado siguiendo los mecanismo de “ocultar, sustituir y mostrar componentes”. Dicho
mecanismo permite adaptar los componentes dependiendo de los roles y del conjunto de dispositivos en uso de los colaboradores. Este mecanismo puede usarse para ocultar los ı́conos no
relacionados con los roles, cuando la pantalla del dispositivo en uso tenga una baja resolución
o sea de tamaño muy pequeño. Además, las aplicaciones pueden optar por calcular la remodelación de la IU en caso de que el dispositivo soporte dicho cálculo o por usar un servidor para
que este les proporcione la IU, considerando las caracterı́sticas del contexto actual (dispositivo
Capı́tulo 5
155
y colaboradores).
El escenario “redistribución del sistema colaborativo en función de la configuración del
grupo” permite adaptar componentes dado el tipo de interacciones (co-localizadas, distribuidas
o hı́bridas) puede llevarse acabo utilizando los dos mecanismos siguientes: 1) “proximidad
lógica” permite identificar si el grupo de colaboradores se encuentra trabajando en la misma
tarea; y, 2) “tipo de trabajo” permite detectar cuando un grupo esta trabajando en un mismo
lugar fı́sico o a distancia.
El escenario “adaptar los medios de contacto y disponibilidad” permite adaptar los medios
de contacto y disponibilidad de los colaboradores puede llevarse acabo al usar los siguientes
tres mecanismos: 1) “similaridad de actividades” permite determinar la similaridad de las
actividades de dos colaboradores, 2) “disponibilidad de un colaborador” permite calcular la
disponibilidad del colaboradores al usar la similaridad de las actividades del usuario a contactar
y el que desea hacer el contacto, y 3) “medios de contacto” permite definir los medios de contacto
considerando la disponibilidad y el hardware de los colaboradores mencionados.
Existen dos escenarios que no se muestran en la tabla, pero pueden ser parcialmente implementados usando los mecanismos existentes. Estos escenarios corresponden a: “adaptar la
información” (cf. sección 4.8) y “uso de diferentes modalidades en la notificación” (cf. sección
4.9).
El escenario “adaptar la información”, que tiene como objetivo proveer información dado un
contexto determinado, puede implementarse casi por completo al usar los siguientes mecanismos: 1) “ocultar, sustituir y mostrar componentes” puede usarse para proveer información
necesaria dado el rol del colaborador y el dispositivo en uso, 2) “proximidad lógica” nos permitirá saber el momento en que entra un colaborador a un lugar especı́fico y ası́ proveer la
información adecuada dado su rol y actividades y 3) “similaridad de actividades” permite detectar la similaridad de actividades entre dos colaboradores, dicho mecanismo permitirá ofrecer
información entre colaboradores dada sus actividades actuales o potenciales.
El escenario “uso de diferentes modalidades en la notificación” tiene como objetivo notificar
usando diferentes modalidades. Este escenario se puede implementar parcialmente al usar
los siguientes dos mecanismos: 1) “proximidad lógica” para conocer en donde se encuentra
el colaborador y ası́ determinar si esta solo o acompañado, y 2) “similaridad de actividades”
para determinar si la actividad del colaborador que genera la actividad esta relacionada con la
actividad del que potencialmente recibirá dicha notificación.
156
Capı́tulo 6
Validación del marco Xare
6.1
API del marco Xare
El marco para la adaptación al contexto de uso se compone de tres capas: espacio de trabajo,
adaptación y detección (cf. Figura 6). Los componentes con letras grises, e.g., espacio de
trabajo privado y compartido, de la figura 6 corresponden a los componentes que no se utilizan
en este escenario.
La capa detección se encarga de detectar tanto el contexto interno (e.g., objeto compartido
en uso) como el contexto externo del sistema (e.g., los colaboradores se encuentran trabajando
en la sala de juntas).
La capa de adaptación, ubicada entre las capas detección y espacio de trabajo, recibe la
información de las dos capas contiguas para analizar si los nuevos cambios contextuales originan alguna de las siguientes adaptaciones: remodelación, redistribución y contexto de uso
(colaborador, conjunto de plataformas y entorno común).
La capa espacio de trabajo permite interactuar con el usuario final, además de mostrar las
adaptaciones usando alguna modalidad.
El componente intermediario en cualquiera de las capas permite pasar información de una
capa a otra, ya que dichos componentes direccionan las solicitudes recibidas y las respuestas
generadas. De esta manera al agregar un nuevo componente en cualquiera de la capas solo se
le debe informar al respectivo componente intermediario sin necesidad de modificar el resto de
los componentes.
La funcionalidad del resto de los componentes es detallada cuando se describe el funcionamiento del escenario propuesto dentro del marco.
Cuando un dispositivo tiene suficientes capacidades para almacenar y procesar las IU adecuadas, la aplicación en ejecución es capaz de adaptarse por si misma de manera autónoma.
157
158
Sin embargo, sin considerar las computadoras portátiles, la mayorı́a de los dispositivos podrı́an
necesitar una entidad externa (e.g., servidores) para desplegar una IU adecuada. La entidad
externa considera las caracterı́sticas de hardware y software del dispositivo huésped, para identificar la IU. Esta tarea es lograda por dos técnicas las cuales son:
1. los dispositivos móviles toman la iniciativa de informar a la entidad externa acerca de
sus propias capacidades. Esta solución es adecuada para soluciones basadas en la Web,
donde los dispositivos móviles actúan como clientes y la entidad externa como servidor;
2. la entidad externa pregunta a los dispositivos móviles acerca de sus capacidades. Esta
opción es adecuada cuando los dispositivos móviles tienen capacidades para responder
peticiones.
6.2
Medio de contacto y disponibilidad”
6.2.1
Dimensiones abordadas en esta propuesta
En el escenario se abordan dos adaptaciones al contexto, los cuales son: disponibilidad y
medios de contacto. Ambas adaptaciones son analizadas considerando las diez dimensiones que
la mayorı́a pertenecen a los problemas encontrados en la interfaz plástica [Vanderdonckt, et al.,
2008]. En la tabla 5 se resume las dimensiones abordadas en este escenario.
Lo que sigue corresponde a dos escenarios: disposnibilidad y objetos referenciados. Verificar
si corresponde al descrito arriba Las dimensiones que están involucradas en la adaptación del
medio de contacto y la disponibilidad al contexto corresponden al grupo de colaboradores
(GrupoDeColaboradores) y al conjunto de plataformas (ConjuntoDePlataformas). Las clases
involucradas en esta propuesta corresponden a las clases: Hardware, Software, Actividad,
MedioDeContacto y Disponibilidad, las cuales se encuentran en marcadas con lı́nea gruesa
de color negro (cf. Figura 5).
La clase Actividad tiene varios métodos y atributos, solo que por cuestiones de espacio
se especifican los más representativos. Además, la clase Actividad se asocia consigo misma
para determinar la similitud entre las actividades de dos colaboradores. La similitud entre
actividades se realiza mediante el método similitud que tiene como parámetros de entrada
todas las actividades de los dos colaboradores (Ac1 y Ac2), incluyendo la actividad actual de
ambos colaboradores. El método similitud implementa las reglas mostradas en la tabla 1.
falta diagrama
La clase Disponibilidad depende de la clase Actividad para usar el método similitud, el cual
regresa la similitud entre el colaborador observado y el observador. El método disponibilidad requiere la similitud entre las actividades además de conocer la fecha lı́mite de la actividad actual,
Capı́tulo 6
159
del colaborador observado, para aplicar las reglas mostradas por el mecanismo de Disponibilidad
(cf. Tabla 2).
Otra de las clases importantes en esta propuesta es el MedioDeContacto que depende de
varias clases, las cuales son: Hardware, Software, Actividad y Disponibilidad. Mediante las
dependencias, la clase MedioDeContacto obtiene una serie de parámetros, e.g., el hardware que
está utilizando cada colaborador y el software disponible para llevar a cabo algún medio de
comunicación.
La clase Hardware debe determinar los dispositivos en uso de los colaboradores a través del
método hardDisponible. Dicho método requiere como parámetro el nombre del colaborador (o
un identificador de identidad) en cuestión. El método hardMediosContacto busca los componentes del dispositivo necesarios para llevar a cabo los medios de contacto, e.g., este método
verificar la existencia de una cámara web, altavoces y micrófono para la video-conferencia. En
el caso de la clase Software, esta se encarga de buscar que aplicaciones permiten la comunicación entre los colaboradores por medio del método softMediosContacto, cuyo parámetro de
entrada es el dispositivo a analizar.
El medio de contacto es calculado dada la similitud entre las actividades o la disponibilidad
del colaborador observado. Cuando se calcula el medio de contacto considerando la similitud entre las actividades, el método medioActividad realiza el cálculo usando la tabla 3 cuyos
parámetros corresponden a: 1) similitud entre actividades, 2) hardware disponible y 3) software
disponible. En el caso de calcular los medios de contacto tomando como parámetro principal
la disponibilidad, del colaborador observado; el método encargado del cálculo es medioDisponibilidad. Este método requiere de las reglas mostradas en la tabla 4, ası́ como tres variables:
1) disponibilidad del colaborador observado, 2) hardware disponible y 3) software disponible.
Tanto el método medioActividad y medioDisponibilidad pueden requerir usar las preferencias
de los medios de contacto establecidos por el colaborador, los cuales se obtienen de la clase
padre Preferencia.
El contexto de uso de los sistemas cooperativos se refiere a la tercia: grupo de colaboradores,
conjunto de plataformas y entorno común. Tanto la disponibilidad como el medio de contexto
se adaptan al grupo de colaboradores; en cambio, el medio de contexto es el único que se adapta
al conjunto de plataformas y al entorno común. La adaptación al grupo de colaboradores por
parte de la disponibilidad se hace al consideras las actividades de los colaboradores involucrados
(observado y observador). La adaptación al grupo de colaboradores por parte de los medio
de contacto se lleva a cabo al considerar la disponibilidad y las preferencias del colaborador
observado, y la similitud de actividades entre el colaborador observado y el observador. La
adaptación a la plataforma se realiza al solicitar tanto el hardware como el software actual
de los colaboradores para comunicarse mediante los medios de contacto, e.g., para una videoconferencia se requiere de hardware (e.g., cámara web, altavoces y micrófono) y se software
que permita el dialogo (e.g., Google talk y Skype). La adaptación al entorno ocurre cuando
el teléfono de Sandy busca un dispositivo de cómputo que pueda ser usado para llevar a cabo
la video-conferencia, los lugares en donde se busca este dispositivo es por donde Sandy va
160
caminando.
Dimensión
Contexto de Uso
Percutor de plasticidad
Grano de adaptación
Grano
de
recuperación
Meta-IU
Adaptación
V
Dimensión
Despliegue de la IU
Adaptación
X
V
Espacio tecnológico
X
V
Tipo de adaptación
V
X
V
V
Tipo de entidad
V
El percutor de plasticidad [Vanderdonckt, et al., 2008] considera la adaptación por remodelación, re-distribución y migración. Este escenario considera la adaptación por remodelación al ocultar al colaborador los iconos de los medios de contacto no permitidos.
En consecuencia la interfaz de usuario cambia para mostrar solo aquellos medios de contacto
disponibles para el colaborador.
El grano de adaptación [Vanderdonckt, et al., 2008] señala el grado en que la interfaz de
usuario ha sido metamorfoseada después de la adaptación. El grano de adaptación se clasifica
en: a) pixel, b) interactor, c) espacio de trabajo e d) interfaz de usuario completa. La interfaz de
usuario del escenario se remodela a nivel interactor al momento de que el colaborador observador
da clic sobre la foto de un colega, en ese momento aparece un menú desplegable que actualiza la
disponibilidad. El medio de contacto también sigue una remodelación a nivel interactor porque
los iconos no accesibles, tanto en el menú desplegable como en la ventana medios de contacto,
están ocultos.
El grano de recuperación del estado [Vanderdonckt, et al., 2008] caracteriza el esfuerzo de
los usuarios que deben realizar para continuar su actividad después de ocurrida la adaptación.
Tres tipos de granos de reanudación son posibles: a) acción fı́sica, b) tarea y c) sesión. En
el escenario no se considera la recuperación del estado porque posiblemente no se pierda la
información al mostrar la disponibilidad ni el medio de contacto del colaborador.
El concepto de Meta-Interfaz de Usuario (Meta-IU) [Vanderdonckt, et al., 2008] se define
como la simplificación de un entorno de desarrollo de usuario final. La meta-IU considera
cuatro niveles: 1) plasticidad en la propia meta-IU, 2) meta-IU sin negociación, 3) meta-IU
con negociación y 4) inexistente. En el escenario propuesto se implementa una meta-IU con
negociación. Dicha meta-IU se ejecuta cuando el colaborador observador coincide con el colaborador observado en más de una aplicación para llevar a cabo la comunicación, e.g., aplicaciones
de mensajerı́a instantánea como Google Talk, Windows Live Messenger y el mensajero nativo
del espacio de trabajo. En ese caso se le proporciona al colaborador observador las opciones
disponibles a través de una ventana.
Despliegue de la interfaz de usuario [Vanderdonckt, et al., 2008] permite conocer si al realizar
la adaptación plástica se utilizan interfaces de usuario: a) prefabricadas o b) generadas en
Capı́tulo 6
161
tiempo de ejecución. En este escenario no se provee la información suficiente para determinar la
implementación de las interfaces de usuario, pero podrı́a generarse IU prefabricadas o generadas
en tiempo de ejecución.
El Espacio Tecnológico (ET) [Vanderdonckt, et al., 2008] es un contexto de trabajo que incorpora un conjunto de conceptos asociados, bases de conocimientos, herramientas, habilidades
requeridas y posibilidades. Los espacios tecnológicos se dividen de la siguiente manera: intraET, interET y multi-ET. En este escenario no se consideró el espacio tecnológico, pero podrı́a
aplicarse multi-ET al proveer la disponibilidad y los medios de contacto en algunos dispositivos
de manera gráfica y en otros, audio.
Tipo de adaptación [Abowd et al., 1999] comprende las siguientes tres maneras: 1) presentación de información y servicios al usuario, 2) ejecución automática de un servicio e 3)
información aumentada. La disponibilidad como en el medio de contacto se enfoca a la presentación de información y servicios al usuario. El mecanismo de la disponibilidad muestra el
estado de disponibilidad del colaborador dependiendo de las variables contextuales del observador como del observado. Por otro lado, el mecanismo que calcula los medios de contacto solo
muestra las opciones disponibles que tiene el colaborador observador. Aún cuando la disponibilidad y el medio de contacto hacen operaciones para determinar las funcionalidades necesarias,
al final de dichas operaciones solo muestra la información.
Las variables contextuales se refiere a las variables relevantes que los sistemas consideran para
llevar a cabo la adaptación [Ghiani et al., 2009]. Las variables contextuales para la disponibilidad corresponde a: similitud entre actividades del colaborador observado y el observador, y
la fecha lı́mite de la actividad actual del colaborador observado. En el caso de los medios de
contacto, las variables contextuales se refieren a: similitud entre actividades del colaborador
observado y el observador, la disponibilidad del colaborador observado y la preferencia respecto
a los medios de contacto del colaborador observado.
Tipo de entidad [Olivares, 2011] se refiere a considerar una sola entidad (e.g., un usuario o
un dispositivo) o varias entidades a lo largo de la ejecución del sistema. El escenario considera
múltiples entidades ya que toma en cuenta variable de dos colaboradores de forma simultánea
para calcular tanto la disponibilidad como el medio de contacto.
6.2.2
Relación entre la propuesta y el marco de adaptabilidad
plástica
Esta sección se encuentra dividida en dos partes: la primera especifica la funcionalidad de cada
capa y la segunda describe el proceso necesario para llevar a cabo el escenario propuesto. En
la segunda parte se resalta el flujo de información entre cada capa, ası́ como la relación entre
la capa y los mecanismos de los diagramas de bloques.
162
Descripción del escenario dentro del marco
La adaptación al contexto a través del medio de contacto y la disponibilidad empieza desde
la capa superior, espacio de trabajo, ya que el usuario ingresa al espacio de trabajo. Una vez
que el espacio de trabajo identifica al colaborador conectado envı́a dicha información a la capa
de adaptación y detección. Las reglas de la capa de adaptación determinan que la identidad
del colaborador tiene que ser tratada en el componente contexto de uso, perteneciente a la
capa de adaptación. La capa de adaptación envı́a la identificación del colaborador hacia la
capa detección para que se actualice el registro del colaborador, i.e., en la base de datos de
colaboradores se registra la hora y fecha de ingreso del colaborador al espacio de trabajo.
Por su parte el componente colaborador solicita información (e.g., roles y actividades asociadas al colaborador) a la capa detección para adaptar el espacio de trabajo al colaborador
que recién ingreso (e.g., mostrar las aplicaciones necesarias para llevar a cabo sus actividades).
Figura 6. Marco de adaptabilidad plástica para sistemas colaborativos
Adaptación de la disponibilidad al contexto
El colaborador, después de identificarse, puede establecer su medio de contacto y su disponibilidad, manual o automática, en la capa espacio de trabajo mediante una ventana de configuración
del medio de contacto y disponibilidad. La primera opción a configurar es la disponibilidad
puesto que puede ser requerida para establecer los medios de contacto. Cuando se establece la
disponibilidad de manera manual, el usuario selecciona simplemente el estado de disponibilidad,
e.g., alcanzable si es posible.
En el caso de que un colaborador permita que su disponibilidad sea establecida de manera
automática, como se observa en el siguiente párrafo proveniente del escenario: Isaac ingresa al
espacio de trabajo ... El espacio de trabajo compartido define la disponibilidad de Isaac como:
1) “ocupado” para todas la personas que están fuera de la preparación del documento técnico;
2) “alcanzable si es posible” para los colegas cuya actividad actual no es similar a la de Isaac
pero su actividad potencial lo es (en términos de los objetos compartidos), y 3) “accesible”
para los colegas cuya actividad actual es similar a la de Isaac.
Describiendo el proceso anterior, el espacio de trabajo envı́a hacia la capa adaptación la
instrucción de calcular automáticamente la disponibilidad del colaborador. El intermediario de
la capa de adaptación recibe dicha instrucción, posteriormente este componente envı́a dicha instrucción al componente colaborador. Cuando el componente colaborador recibe la instrucción
de calcular automáticamente la disponibilidad establece las reglas a seguir, en el escenario propuesto se da una sugerencia de dichas reglas que se resumen en la tabla 2. En la tabla 2 se sugiere
establecer la disponibilidad dependiente de la similitud entre las actividades del colaborador
observado y el observador, ası́ como de la fecha lı́mite de la actividad actual del colaborador.
Retomando parte de un párrafo del escenario que ejemplifica cuando un colaborador necesita
conocer la disponibilidad de otro, es el siguiente: Por un momento, Sandy escribe la sección de
Capı́tulo 6
163
introducción, posteriormente interrumpe esta actividad para contactar a Isaac. Ella coloca su
cursor sobre la foto de Isaac (en el widget de conciencia de colaboradores) y como resultado,
un menú desplegable aparece para mostrar: la disponibilidad de Isaac y el medio de contacto
para comunicarse con él.
Cuando Sandy coloca su cursor sobre la foto de Isaac, la capa espacio de trabajo solicita a la
capa adaptación dos datos: 1) la disponibilidad de Isaac y 2) los medios de contacto. En la capa
adaptación, el intermediario al recibir dicha solicitud la transfiere al componente colaborador.
La capa colaborador solicita a la capa detección las actividades actuales y potenciales, ası́ como
la fecha lı́mite de la actividad actual de Isaac (colaborador observado). Cuando el componente
colaborador obtiene la información solicitada, este componente primero calcula la similitud
entre actividades para después calcular la disponibilidad de Isaac. Al terminar los cómputos, el
componente colaboradores regresa la disponibilidad de Isaac al componente intermediario, a su
vez este componente le regresa la disponibilidad a la capa espacio de trabajo. La capa espacio
de trabajo le informa a la aplicación, que solicitó la disponibilidad de Isaac, la respuesta.
Adaptación de los medios de contacto al contexto Los medios de contacto pueden ser establecidos manualmente o automáticamente dentro de la ventana “Medios de contacto”, la cual está
contenida en la capa espacio de trabajo. Un ejemplo de establecer manualmente los medios de
contacto se muestra en el siguiente párrafo, el cual pertenece al escenario mostrado al inicio
de esta propuesta: Sin embargo, Isaac decide establecer su medio de contacto como sigue: 1)
cuando él esté “ocupado”, él puede ser solamente contactado por correo electrónico, ası́ que
temas. . . ; 2) cuando él esté “alcanzable si es posible”, él puede ser solo contactado por mensajerı́a instantánea, ası́. . . , y finalmente 3) cuando él esté “accesible”, él puede ser contactado
por video-conferencia, audio o mensajerı́a instantánea porque. . .
Cuando el colaborador selecciona la opción manual, el espacio de trabajo solo debe desplegar los medios de contacto soportados por los dispositivos que actualmente está usando el
colaborador. A consecuencia, el espacio de trabajo solicita a la capa adaptación los medios
de contacto soportados por los dispositivos. La solicitud recibida por la capa adaptación es
transferida al componente intermediario de dicha capa, para que este dirija la solicitud al componente plataforma. Este último componente solicita a la capa detección los dispositivos en
uso del colaborador, dicha solicitud es a través del componente intermediario. El componente
intermediario, de la capa detección, envı́a la solicitud al componente hardware para que este
indique cuales son los dispositivos en uso.
Después de que el componente plataforma recibe los dispositivos en uso, e.g., computadora
portátil, ejecuta la clase Hardware, de la figura 5, para verificar la existencia de los dispositivos
auxiliares y aplicaciones necesarias para llevar a cabo la comunicación, e.g., para la videoconferencia se necesitan detectar los siguientes dispositivos auxiliares: cámara web, altavoces y
micrófono, y las aplicaciones necesarias para una vide-conferencia pueden ser: Skype, Oovoo,
Google talk, etc. Dicha solicitud llega al intermediario, de la capa detección, este componente
solicita a los componentes hardware y software determinar la existencia de cámara web y
altavoces ası́ como las aplicaciones necesarias para llevar a cabo la comunicación. La detección
164
de dichos dispositivos y aplicaciones puede realizarse mediante programas o recurrir a las bases
de datos para extraer dicha información.
Después de obtener la información solicitada, los componentes hardware y software regresan
la información al intermediario, de la capa detección, para que sea enviada a la capa adaptación.
Esta capa al recibir la información la analiza mediante reglas para determinar los medios de contacto disponible, dado las caracterı́sticas de hardware y software del equipo en uso. Finalmente,
dicha información es enviada a la capa espacio de trabajo.
En la capa espacio de trabajo se informa a la aplicación que solicitó los medios de contacto
disponibles, en este caso a la ventana medios de contacto, para que las opciones disponibles
sea mostrada al colaborador. Posteriormente, el colaborador tiene que determinar su medio de
contacto considerando su disponibilidad o la actividad, ası́ como el medio de contacto requerido.
En el proceso anterior se describió la manera en que interviene el marco propuesto cuando un
usuario determina manualmente sus medios de contacto. La siguiente explicación es referente
cuando el colaborador decide que el medio de contacto sea establecido por el espacio de trabajo.
El espacio de trabajo calcula el medio de contacto basándose en la actividad, pero podrı́a basarse
dicho cálculo en la disponibilidad. En el escenario se proporciona los medios de contacto
basándose en la similitud de las actividades. El siguiente párrafo fue tomado del escenario:
El espacio de trabajo compartido también determina que Sandy puede ser contactada por: 1)
anotaciones privadas en el texto o mensajerı́a instantánea por colegas cuyas actividades (actual
o potencial) son muy similares a las suyas y 2) los medios de comunicación de la preferencia de
Sandy en cualquier otro caso.
El cálculo automático del medio de contacto frecuentemente lo hace el espacio de trabajo en el
momento que un colaborador solicita comunicarse con un colega. La solicitud se hace cuando el
colaborador coloca su cursor sobre la foto de un colega como se muestra en el siguiente párrafo,
el cual fue tomado del escenario: Al momento de que Alice se encuentra realizando la actividad
de revisar la sección de desarrollo, ella requiere contactar a Sandy... Cuando ella coloca su
cursor sobre la foto de Sandy, Alice observa que la disponibilidad de Sandy es “Accesible”,
dado que ambas están trabajando en el mismo reporte técnico. También Alice nota que los
medios de contacto disponible de Sandy corresponden a la mensajerı́a instantánea y correo
electrónico, ya que ambos medio son de la preferencia de Sandy. Al seleccionar Alice. . .
Cuando Alice coloca su cursor sobre la foto de Sandy aparece la disponibilidad y los medios
de contacto relacionados con Sandy. Internamente, la aplicación que usa Alice solicita a la capa
espacio de trabajo la disponibilidad y los medios de contacto relacionados con Sandy. En esta
parte de la sección se abordada solo los medios de contacto ya que la disponibilidad fue tratada
previamente.
La capa espacio de trabajo solicita a la capa adaptación los medios de contacto en común
entre Alice y Sandy, tomando en cuenta la preferencia de Sandy para ser contactada. El
componente intermediario de la capa adaptación solicita al componente colaborador los medios
de contacto disponibles que tiene Alice para contactar a Sandy. A su vez, este componente
Capı́tulo 6
165
solicita a la capa detección consultar si Sandy estableció los medios de contacto. En el caso de
recibir una respuesta negativa, el componente colaborador debe aplicar las reglas de la tabla 3.
La solicitud de verificar si Sandy estableció los medios de contacto recibida por la capa
detección es transferida al componente intermediario. Este componente accede a la base de
datos colaboradores y accede a la información solicitada. Entre los componente intermediarios
se comunican para informar que Sandy no estableció manualmente los medios de contacto.
Cuando el componente colaborador recibe la respuesta negativa a su solicitud, este componente
calcula la similitud, entre Sandy y Alice, teniendo como resultado que la similitud entre las
actividades potenciales es más o menos similar. El componente colaborador sigue las reglas de
la tabla 3, por tal motivo solicita la preferencia de Sandy ante los medios de contacto a través
de los componentes intermediarios.
Al recibir la solicitud de la preferencia de los medios de contacto de Sandy, el componente
intermediario, de la capa detección, accede a la base de datos colaboradores para extraer la
preferencia de ella. Dicho componente le informa a su sı́mil de la capa adaptación que la
colaboradora Sandy tiene como medio de contacto preferente la mensajerı́a instantánea y el
correo electrónico.
El componente intermediario, de la capa adaptación, transfiere la información recibida al
componente colaborador. El componente solicita nuevamente a la capa detección el hardware y software necesario para llevar a cabo la mensajerı́a instantánea y el correo electrónico.
Posteriormente, el componente colaborador informa al componente re-modelación los iconos
disponibles de los medios de contacto, e.g., Alice tiene solo la opción de mensajerı́a instantánea
y correo electrónico, ası́ que el resto de iconos relacionados con el medio de contacto deben ser
ocultados. El componente re-modelación debe informar a las capas adyacentes cuales son los
iconos disponibles para que la colaboradores Alice contacte a Sandy. Además, el componente
re-modelación debe hacer los cálculos pertinentes para reacomodar los iconos en caso de ser
necesario.
En el caso que exista más de un software para ejecutar el medio de contacto, como ocurre
en el complemento del párrafo anterior perteneciente al escenario, se ofrece al colaborador las
opciones posibles, e.g., Al seleccionar Alice la mensajerı́a instantánea, el espacio de trabajo
le ofrece los posibles medios de contacto (e.g., Google Talk, Windows Live Messenger y el
mensajero nativo del espacio de trabajo) que tienen en común ellas. Alice selecciona Google
Talk. El espacio de trabajo le informa a Sandy que Alice desea contactarlo por medio de
la mensajerı́a; además dicho espacio sugiere usar Google Talk ya que fue la elección de ella.
Finalmente, Alice acepta la comunicación usando el mensajero instantáneo propuesto por Alice.
El componente colaborador envı́a las opciones disponibles a la capa espacio de trabajo mediante el componente intermediario. La capa espacio de trabajo reenvı́a esa información al
componente meta-IU para que este despliegue al colaborador las opciones actuales. Cuando el
colaborador selecciona una opción, dicha información es regresada a la capa adaptación. A su
vez, la capa adaptación envı́a la selección de la aplicación a la capa detección para registrar
dicha acción.
166
6.3
Conclusiones
Gracias a la API presentada en este capı́tulo, los desarrolladores de sistemas colaborativos
plasticos pueden crear sus aplicaciones. Además, ellos pueden ayudarse a usar dicha API,
gracias al escenario presentado, el cual hace uso de dicha API.
Capı́tulo 7
Conclusiones y trabajo a futuro
En la sección 7.1 se presentan las conclusiones hasta el momento y en la sección 7.2 se presenta
el trabajo a desarrollar para terminar este tema de investigación.
7.1
Conclusiones
Cap2. Este capı́tulo muestra una subárea del campo de Interacción Humano-Computadora
(IHM) llamada “Plasticidad de las Interfaces de Usuario”; dicha subárea es importante para
el desarrollo del presente trabajo de investigación porque propone considerar varios puntos
relevantes para crear una interfaz de usuario plástica en la etapa de diseño o en tiempo de
ejecución. También, sistemas plásticos deben informar al usuario final acerca de la nueva
adaptación, ya sea que el usuario intervenga en el proceso de adaptación o solo sea un observador
pasivo.
Varios de los sistemas de ejemplo permiten expresar de manera visual la plasticidad, e.g.,
cambiar de modalidad gráfica a textual cuando el dispositivo no lo soporte; redistribuir la IU
entre dispositivos heterogéneos (e.g., pizarrones electrónicos, PDA, PC y mesas) y adaptarse a
la tarea del colaborador.
En los ejemplos presentados, se observa que la mayorı́a de los sistemas se adaptan a la
plataforma, principalmente estos sistemas se ejecutan sobre PDAs, tablets PC y computadoras
portátiles; otras plataformas menos usadas son pizarrones electrónicos, teléfonos inteligentes o
relojes. Muy pocos de estos sistemas consideran al usuario. La tendencia respecto al usuario
es considerar las tareas (frecuencia y preferencia) o reconocer cuando un mismo usuario está
usando dos o más dispositivos.
Cap3. Los marcos descritos en esta sección fueron seleccionados debido a que implementan
algunas de los caracterı́sticas de las interfaces de usuario plásticas multimodales.
167
168
Dado el análisis de los marcos con respecto al contexto de uso se puede observar que existe la
tendencia en considerar varias peculiaridades del usuario , e.g., el perfil, las tareas asignadas y
el rol, con la finalidad de proveer una mejor adaptación. Las caracterı́sticas anteriores cada vez
consideran aspectos muy finos, e.g., las acciones realizadas dentro del sistema y las preferencias
respecto a un tema. Por otro lado, la adaptación a la plataforma se centra en acoplarse a
las caracterı́sticas que ofrece cada dispositivo de cómputo, pero la tendencia en este punto es
considerar sensores para permitir la conciencia del entorno fı́sico, además de crear clusters de
manera dinámica con los dispositivos al alcance de los usuarios. En cuanto la adaptación al
entorno, los marcos están tendiendo a modelar el entorno fı́sico, e.g., detectar las personas en
un lugar, ası́ como proporcionar información relevante a cada usuario.
Retomando los puntos relevantes de las interfaces de usuario plásticas se observa que los
marcos se inclinan por permitir que los usuarios finales intervengan en la adaptación mediante
una META-IU, ası́ como llevar la adaptación en tiempo de ejecución, dejando de lado los demás
puntos a considerar.
Cap4 El diagrama de clases propuesto puede servir como referencia para crear aplicaciones
plásticas cooperativas ya que se pueden observar las dependencias que existen entre las clases
y las dimensiones del contexto de uso. Dicho diagrama considera la mayorı́a de los escenarios
propuesto en el capı́tulo 4, en especifico aborda los escenarios que tienen implementadas sus
aplicaciones
En la tabla 5.4 se provee mecanismos para implementar cuatro de los ocho escenarios presentados. El escenario que considera los objetos compartidos, el cual se refiere a crear ligas entre
una palabra clave de la mensajerı́a instantáneas y un objeto compartido del editor colaborativo mediante la función Deixis, puede ser implementado mediante el mecanismo 5.2.5. Este
mecanismo podrı́a permitir crear ligas no solo desde la aplicación de mensajerı́a instantánea
sino desde cualquier otra aplicación, esto se puede lograr gracias a que la clase Link es parte
del SharedWorkspace.
En el caso del escenario que permite la modificación de componentes mediante la ocultación,
agregación o sustitución puede ser implementado siguiendo los mecanismo 5.2.4. Dicho mecanismo permite adaptar los componentes dependiendo de los roles del colaborador y del conjunto
de dispositivos en uso. Este mecanismo puede usarse para ocultar los ı́conos no relacionados
con el rol, cuando la pantalla del dispositivo en uso tenga una baja resolución o sea de tamaño
muy pequeño. Además las aplicaciones pueden optar por calcular la remodelación de la IU en el
caso de que el dispositivo soporte dicho cálculo o usar un servidor para que este les proporcione
la IU considerando las caracterı́sticas del contexto (dispositivo y colaboradores) actual.
El escenario que permite adaptar componentes en las interacciones co-localizadas, distribuidas o hı́bridas puede llevarse acabo utilizando los dos mecanismos siguientes: 1) el mecanismo 5.2.6 permitirá identificar si el grupo de colaboradores se encuentra trabajando en la
misma tarea; mientras que, 2) 5.2.7 que permite detectar cuando un grupo esta trabajando en
un mismo lugar fı́sico o a distancia.
Capı́tulo 7
169
El escenario que permite adaptar los medios de contacto y disponibilidad de los colaboradores
puede llevarse acabo al usar los siguientes tres mecanismos: 1) 5.2.1 permite determinar la
similaridad de las actividades de dos colaboradores, 2) 5.2.2 permite calcular la disponibilidad
del colaboradores al usar la similaridad de las actividades del usuario a contactar y el que
desea hacer el contacto, y 3) 5.2.3 permite definir los medios de contacto considerando la
disponibilidad y el hardware de los colaboradores mencionados.
Existen dos escenarios que no se muestran en la tabla, pero pueden ser parcialmente implementados usando los mecanismos existentes. Estos mecanismos corresponden a: 4.8 y 4.9.
El escenario 4.8, que tiene como objetivo proveer información dado un contexto determinado,
puede implementarse casi por completo al usar los siguientes mecanismos: 1) 5.2.4 puede usarse
para proveer información necesaria dado el rol del colaborador y el dispositivo en uso, 2) 5.2.7
nos permitirá saber el momento en que entra un colaborador a un lugar especı́fico y ası́ proveer
la información adecuada dado su rol y actividades y 3) 5.2.1 permite detectar la similaridad
de actividades entre dos colaboradores, dicho mecanismo permitirá ofrecer información entre
colaboradores dada sus actividades actuales o potenciales.
El escenario 4.9 tiene como objetivo notificar usando diferentes modalidades. Este escenario
se puede implementar parcialmente al usar los siguientes dos mecanismos: 1) 5.2.7 para conocer
en donde se encuentra el colaborador y ası́ determinar si esta solo o acompañado, y 2) 5.2.1
para determinar si la actividad del colaborador que genera la actividad esta relacionada con la
actividad del que potencialmente recibirá dicha notificación.
Ver. Anterior Se propone un marco conceptual para orientar a los desarrolladores con aplicaciones adaptativas al contexto considerando una meta-IU con o sin negociación. La adaptación
considerada incluye el contexto de uso, la remodelación y la redistribución, sin dejar de lado la
producción de los colaboradores ya que se propone un modulo para la recuperación del sistema
Algunos componentes del contexto de uso es el medio de contacto y a la disponibilidad,
los cuales resultan interesantes de analizar cuando el sistema interviene para establecer de
manera automática las opciones disponibles. El medio de contacto ofrece a cada colaborador las
herramientas disponibles para ser contactado, dependiendo de algunas caracterı́sticas propias
(plataforma, disponibilidad, actividad y el tiempo final de la actividad actual) del colaborador
ası́ como de los colegas que desea contactarlo. El estado de disponibilidad de un colaborador
depende de la similitud entre su actividad y la de sus colegas (cf. Escenario 4.6).
Usando las dimensiones propuestas en la sección 2.9 del capı́tulo 2, las cuales se refieren
a: mono-entidad o multi-entidad, variables contextuales y tipo de adaptación (presentación,
ejecución y aumentación), sobre el diagrama de clases. En este capı́tulo se puede concluir que
una mı́nima parte del diagrama considera la mono-entidad, en especifico para la asignación de
roles o la disponibilidad, ya que se considera a cada colaborador por separado. En cambio,
la gran parte del diagrama considera la situación de varias entidades de forma simultánea,
e.g., un documento formado por varios objetos compartidos es creado a partir de uno o varios
colaboradores y la interfaz de usuario de cada colaborador se puede ver restringido por la
170
plataforma de los colaboradores y sus actividades que cada uno esté desempeñando al momento
de contactar a un colega. Las variables contextuales que intervienen en la propuesta de los
sistemas de cooperativos adaptativos (ver diagrama de clases) son varias, e.g., para establecer
el medio de contacto se requiere conocer la plataforma, la actividad, la disponibilidad del grupo
de colaboradores y la fecha actual, por otra parte la acción de los colaboradores puede servir
para que la aplicación detecte cuando dos o mas colaboradores están haciendo referencia sobre
un mismo objeto compartido, otro ejemplo es cuando la aplicación requiere conocer tanto el rol
del colaborador para mostrar las herramientas relacionadas, finalmente las condiciones grupales
permiten mostrar si los colaboradores trabajan de manera colocalizada o distribuida.
Analizando el tipo de adaptación (presentación, ejecución y aumentación) sobre la propuesta presentada podemos concluir que se aplican todos los tipos de adaptación en diferentes
situaciones, El tipo presentación es aplicado cuando se proporcionan los medios de contacto
para establecer comunicación con un colaborador, en este caso el sistema presenta solo aquellas
opciones que están disponibles para ambos colaboradores. El tipo ejecución se lleva a cabo
cuando el sistema asigna de manera automática el rol, la disponibilidad y el medio de contacto.
Finalmente, la información aumentada se proporciona cuando el sistema detecta que dos o
mas usuarios están haciendo referencia a un objeto compartido, e.g., un colaborador describe
un diagrama y otro modifica el mismo diagrama, otro ejemplo de la información aumentada
corresponde cuando dos o mas usuarios ligan un objeto compartido, en este caso ellos pueden
tener a la vista dicho objeto al dar clic sobre la liga.
7.2
Trabajo a futuro
El trabajo que falta para terminar este tema de tesis es el siguiente:
• Enriquecer el diagrama de clases del contexto de uso con los demás escenarios, hasta el
momento solo se han agregado dos escenarios
• Revisar el marco conceptual
• Crear las aplicaciones de prueba
• Modificar el articulo rechazado con las propuestas indicadas, con el objetivo de someterlo
a una revista.
• Escribir la tesis
Apéndice A
Publicaciones
Publicaciones en revistas indexadas
• Dominique Decouchant, Sonia Mendoza, Gabriela Sánchez, José Rodrı́guez, “Adapting
groupware systems to changes in the collaborator’s context of use. Expert Syst. Appl.
40(11): 4446-4462 (2013)
Publicaciones en congresos internacionales
• Michael Romero, Sonia Mendoza, Gabriela Sánchez, ”A framework for developing contextaware applications for co-located collaborative work”, CCE, México, D.F. (México),
September 30 - October-4, 2013.
• Sonia Mendoza, Dominique Decouchant, Gabriela Sánchez, José Rodrı́guez and Alfredo
Piero Mateos Papis, ”User Interface Plasticity for Groupware”, In Proceedings of the
International Conference on Digital Information and Communication Technology and its
Applications (DICTAP’2011), Communications in Computer and Information Science
(CCIS) Series, Vol. 166, Part I, Springer, pp. 380-394, Dijon (France), June 21-23 2011
• Gabriela Sánchez, Sonia Mendoza, Dominique Decouchant, Lizbeth Gallardo-López, and
José Rodrı́guez, ”Plasticity of Interaction Interfaces: the Study Case of a Collaborative
Whiteboard”, In Proceedings of the 16th Collaboration Researchers’ International Workshop in Groupware (CRIWG’2010), LNCS 6257, Springer, pp. 265-280, Maastricht (The
Netherlands), 20-23 September 2010.
Publicaciones en congresos nacionales
• Gabriela Sánchez, Sonia Mendoza y Dominique Decouchant, ”Adaptacion por plasticidad
de sistemas de cómputo interactivos, ”VII Encuentro Participación de la Mujer en la
171
172
Publicaciones
Ciencia, Centro de Investigaciones en Óptica, ISBN 978-607-95228-1-0, 5 páginas, León
Guanajuato (México), Mayo 2010.
Participación
• Consorcium doctoral, 16th Collaboration Researchers’ International Workshop in Groupware (CRIWG’2010), LNCS 6257, Springer, pp. 265-280, Maastricht (The Netherlands),
20-23 September 2010.
Referencias
[Abowd et al., 1999] Abowd, G. D., Dey, A. K., Brown, P. J., Davies, N., Smith, M., and
Steggles, P., Towards a better understanding of context and context-awareness, In Gellersen,
H.-W., editor, HUC, Vol. 1707, Lecture Notes in Computer Science, pp. 304–307. Springer,
1999.
[Amato and Straccia, 1999] Amato, G. and Straccia, U., User profile modeling and applications
to digital libraries, Abiteboul, S. and Vercoustre, A.-M (Eds): ECDL ’99, LNCS 1696, pp.
184-197, Springer-Verlag Berlin Heidelberg, 1999.
[Balme et al., 2005] L. Balme, A. Demeure, G. Calvary y J. Coutaz, Sedan-Bouillon: A Plastic
Web Site, Plastic Services for Mobile Devices (PSMD), Workshop hel in conjunction with
Interact’05, pp. 1-3, Rome, 2005 .
[Balme et al., 2004] Balme, L., Demeure, A., Barralon, N., Coutaz, J. and Calvary, G.,
CAMELEON-RT: A Software Architecture Reference Model for Distributed, Migratable,
and Plastic User Interfaces, In EUSAI 2004 - Ambient Intelligence - Second European
Symposium, Markopoulos, P., Eggen, B., Aarts, E. and Crowley, J. (Eds.), pp. 291-302,
Eindhoven, The Netherlands, November 8-11 2004.
[Bastide et al., 2003] Bastide, R., Navarre, D. and Palanque, P., A Tool-Supported Design
Framework for Safety Critical Interactive Systems, Interacting with Computers, Elsevier
Science B., Vol. 15, No. 3, pp. 289-308, pp. 309-328, 2003.
[Beck, 1993] Beck, E., A Survey of Experiences of Collaborative Writing, In Computer Supported Collaborative Writing, Sharples, M. (Eds.), Springer-Verlag, pp. 87-112, 1993.
[Buzzi et al., 2010] Buzzi, M. C., Buzzi, M., Leporini, B., Mori, G. and Penichet, V.,Accessing
Google docs via screen reader, Proceedings of the 12th international conference on Computers helping people with special needs: Part I, pp. 92-99, Vienna (Austria), 2010.
[Calvary et al., 2006] , G. Calvary, J. Coutaz, O. Daassi, V. Ganneau, L. Balme, A. Demeure
and J.-S. Sottet, Métamorphose des IHM et Plasticité: Article de synthèse, Ergo’IA 2006,
pp. 11-18, 2006.
173
174
REFERENCIAS
[Calvary et al., 2004] G. Calvary, J. Coutaz, O. Dâssi, L. Balme and A. Demeure, Towards a
New Generation of Widgets for Supporting Software Plasticity: The ”Comet”, In R. Bastide,
P. A. Palanque and J. Roth (Eds.), EHCI/DS-VIS, pp. 306-324, 2004.
[Calvary et al., 2003] Calvary, G., Coutaz, J., Thévenin, D., Limbourg, Q., Bouillon, L., Vanderdonckt, J., A Unifying Reference Framework for Multi-Target User Interfaces; Interacting with Computers, Elsevier Science B., Vol. 15, No. 3, 289-308, 2003
[Calvary et al., 2002] Calvary G., Coutaz J., Thevenin D., Limbourg Q., Souchon N., Bouillon
L., Florins M. and Vanderdonckt J., Plasticity of User Interfaces: A Revised Reference
Framework,TAMODIA 2002: Proceedings of the First International Workshop on Task
Models and Diagrams for User Interface Design, pp. 127-134, 2002
[Calvary et al., 2001] G. Calvary, J. Coutaz and D. Thevenin, A Unifying Reference Framework
for the Development of Plastic User Interfaces, Lecture Notes in Computer Science, Vol.
2254, pp. 173-194, 2001.
[Cardoso and José, 2009] Cardoso J. and José, R., A Framework for Context-Aware Adaptation
in Public Displays, Lecture Notes in Computer Science,Vol. 5872, pp. 118-127, Springer,
2009
[Cerratto and Rodrı́guez, 2002] Cerratto, T. and Rodrı́guez, H., Studies of ComputerSupported Collaborative Writing Implications for System Design, In Cooperative Systems
Design, IOS Press, pp. 139-154, 2002.
[Churchill et al., 2004] Churchill, E.F., Nelson, L., Denoue, L., Helfman, J., Murphy, P., Sharing multimedia content with interactive public displays: a case study, In: DIS 2004: Proc.
of the 5th conference on Designing interactive systems, pp. 7–16. ACM, New York, 2004.
[Coutaz and Calvary, 2008] Coutaz, J. and Calvary,G., Chapter 56. The Case for User Interface Plasticity, book The Human-Computer Interaction, Handbook: Fundamentals, Evolving Technologies, and Emerging Applications, Ed. Human Factors and Ergonomics, 2007.
[Crease, 2001] M. Crease, A Toolkit of Resource-Sensitive, Multimodal Widgets, PhD Thesis,
Department of Computing Science, University of Glasgow, 2001.
Decouchant, et al., 2013 Decouchant:13 Decouchant, D., Mendoza, D., Sánchez. G. and
Rodrı́guez, J., Adapting groupware systems to changes in the collaborator’s context of use,
Expert Syst. Appl. 40(11), pp. 4446-4462, 2013.
[Demeure et al., 2005] Demeure, A., Balme, L., Calvary, G., and, Coutaz, J., CamNote: A
Plastic Slides Viewer, Plastic Services for Mobile Devices (PSMD), Workshop hel in conjunction with Interact’05, pp. 1-2, Rome (Italy), 2005.
[Derntl and Hummel, 2005] Derntl, M. and Hummel, K., Modeling Context-Aware e-Learning
Scenarios, Third IEEE International Conference on Pervasive Computing and Communications Workshops (PERCOMW’05), IEEE Computer Society, pp. 337-342, Kauai Island,
Hawaii (USA), March 2005.
REFERENCIAS
175
[Dey et al., 2001] Dey, A., Abowd, G., Salber, D., A conceptual framework and a toolkit for
supporting the rapid prototyping of context-aware applications, Hum.-Comput. Interact.,
Vol. 16, No. 2, pp. 97-166, December 2001.
[Dourish and Bellotti, 1992] Dourish, P. and Bellotti, V., Awareness and Coordination in
Shared Workspaces,Proceedings of the ACM Conference on Computer-Supported Cooperative Work CSCW’92 (Toronto, Ontario), 107-114. New York: ACM, pp. 107-114, 1992.
[Dourish, 1996] Dourish, P., Open Implementation and Flexibility in CSCW Toolkits, PhD Thesis, Department of Computer Science, University of London, June 1996.
[Ejigu et al., 2007] Ejigu, D., Scuturici, M. and Brunie, L., An Ontology-Based Approach to
Context Modeling and Reasoning in Pervasive Computing, Pervasive Computing and Communications Workshops, IEEE International Conference on, IEEE Computer Society, pp.
14-19, White Plains, New York (USA), March 2007.
[Gall and Hauck, 1997] Gall, U. and Hauck, F. J., Promondia: A Java-Based Framework for
Real-time Group Communication in the Web, Computer Networks, Vol. 29, No. 8-13, pp.
917-926, 1997.
[Gamma et al., 1995] Gamma, E., Helm, R., Johnson, R. and Vlissides, J., Desing Patterns:
Elements of Reusable Object-Orient Software, Vol. 1, Addison-Wesley, Upper Saddle River
NJ (USA), 1995.
[Gauch, et al., 2007] Gauch, S., Speretta, M., Chandramouli, A. and Micarreli, User profiles
for Personalized information Access, The Adaptive Web, Methods and Strategies of Web
Personalization, Vol. 4321, pp. 54-89, Lecture Notes in Computer Science, Springer, 2007.
[Gettys and Packard] Gettys J. and Packard K., The X Window System, ACM Transactions
on Graphics, Vol. 5, No. 2, pp. 79-109, 1986.
[Ghiani et al., 2009] Ghiani, G., Paternò, F., Santoro, C., and Spano, L. D. Ubicicero: A
location-aware, multi-device museum guide, Interacting with Computers, Vol.21, num 4,
pp.288–303, 2009.
[Grolaux et al,. 2002] D. Grolaux, P. V. Roy and J. Vanderdonckt, FlexClock, a Plastic Clock
Written in Oz with the QTk toolkit, Costin Pribeanu and Jean Vanderdonckt (Eds), TAMODIA, pp. 135-142, 2002.
[Granados, 2011] Granados, L., Integración de los espacios de comunicación, producción y coordinación en un entorno cooperativo, Master thesis, Departament of Computation, Centro
de Investigación y Estudios Avanzados del IPN, December, 2012.
[Grudin, 1988] Grudin, J., Why CSCW Applications Fail: Problems in the Design and Evaluation of Organizational Intserfaces, In Proceedings of the Second Conference on ComputerSupported Cooperative Work (CSCW’88), ACM Press, pp. 85-93, Portland OR (USA),
September 26-28 1988.
176
REFERENCIAS
[Gutwin et al., 1995] Gutwin, C., Stark, G. and Greenberg, S., Support for workspace awareness in educational groupware. Proceeding CSCL ’95 The first international conference on
Computer support for collaborative learning, Indiana (USA), pp.147-156, 1995.
[Utwin et al., 1996] Gutwin, C., Greenberg, S., and Roseman, M., Workspace awareness support with radar views. In Conference companion on Human factors in computing systems:
common ground, CHI ’96, New York, NY (USA), pp. 210–211, 1996.
[Haake et al., 2010] Haake, J., Hussein, T, Joop, B., Lukosch, S., Veiel, D. and Ziegler, J.,
Modeling and exploiting context for adaptive collaboration, International Journal of Cooperative Information Systems, Vol. 19, Nos. 1 & 2, pp 71-120, World Scientific Publishing
Company, 2010.
[Henricksen et al., 2002] Henricksen, K., Indulska, J. and Rakotonirainy, A., Modeling Context
Information in Pervasive Computing Systems, Pervasive Computing In Pervasive Computing, Vol. 2414, pp. 79-117, Springer-Verlag, August 2002.
[Hussein et al., 2010] Hussein, T., Linder, T., Gaulke, W., and Ziegler, J., A framework and an
architecture for context-aware group recommendations, In Kolf- schoten, G. L., Herrmann,
T., and Lukosch, S. (Editors), CRIWG 2010 Collaboration and Technology - 16th International Conference, Lecture Notes in Computer Science, Vol. 6257, pp. 121–128, Maastricht,
The Netherlands, September 20-23, Springer, 2010.
[Jaimes and Sebe, 2005] Jaimes, A. and Sebe, N., Multimodal Human Computer Interaction: a
survey, IEEE International Workhop on Human Computer Interaction in Conjuntion with
ICCV 2005, pp. 1- 16, Beijing, China, 2005.
[Kofod-Petersen and Cassens, 2006] Kofod-Petersen, A. and Cassens, J.,Using activity theory
to model context awareness, Lecture Notes on Artificial Intelligence In Modeling and Retrieval of Context, Vol. 3946, pp. 1-17, Springer Verlag, 2006.
[Kouadri and Brézillon, 2004] Kouadri, G. and Brézillon, P., Modeling Context-Based Security
Policies with Contextual Graphs, Second IEEE Annual Conference on Pervasive Computing
and Communications Workshops, IEEE Computer Society, pp. 28-32, Orlando, Florida
(USA), March 2004.
[Legin et al., 2005] Legin, A., Rudnitskaya, A., Seleznev, B., Vlasov, Yu., Electronic tongue for
quality assessment of ethanol, vodka and eau-de-vie,, Analytica Chimica Acta, Vol. 534, pp.
129-135, April 2005.
[Lucero et al., 2010] Lucero, A., Keranen, J., and Hannu, K. Collaborative Use of Mobile
Phones for Brainstorming, In Proceedings of the 12th international conference on Human
computer interaction with mobile devices and services, MobileHCI ’10, ACM, pp. 337-340,
New York (USA), September 2010.
REFERENCIAS
177
[Luyten et al., 2003] Luyten, K., Van Laerhoven, T., Coninx, K. and Van Reeth, F., Runtime
transformations for modal independent user interface migration, Interacting with Computers, Elsevier Science B., Vol. 15, No. 3,329-347, 2003.
[Myers, 2001] Myers, B. A.,Using Handhelds and PCs Together, Communication of the ACM,
Vol. 44, No 11, pp. 34-41, November 2001.
[Olivares, 2011] Olivares, A., ”Arquitectura para el soporte de contexto de uso en sistemas colaborativos, Master thesis, Departament of Computation, Centro de Investigación y Estudios
Avanzados del IPN, December, 2011.
[Oviatt, 1999] Oviatt, S.L., Ten Myts of Multimodal Interaction, Comm. ACM, pp. 74-81, 1999.
[Paredes and Fonseca, 2010] Paredes, H. and Fonseca, B., PaperFlow/R: A cooperative environment for the conception and production of scientific publications, Proceedings of the
2010 14th International Conference on Computer Supported Cooperative Work in Design,
CSCWD 2010, Shen, W., Gu, N., Lu, T., Barthès, Jean-Paul and Luo, J. (Eds.), IEEE, pp.
740-743, Shanghai (China), 2010.
[Paterno and Mancini, 1997] Paterno, F., Mancini, C., Meniconi, S., ConcurTaskTrees: A Diagrammatic Notation for Specifying Task Models, In INTERACT ’97: Proceedings of the
IFIP TC13 Interantional Conference on Human-Computer Interaction, pp. 362-369, 1997.
[Paterno and Santoro, 2012] Paterno, F. and Santoro, C., A logical framework for multi-device
user interfaces, In proceedings of the ACM SIGCHI Symposium on Engineering Interactive
Computing Systems, Junqueiras Barbosa, S.D., Camposk J.C. Kazman, R. Palanque P.A.,
HArrison, M.D,Reeves, S., pp.4450, ACM Press,Oralando Fl, 2012.
[Paterno et. al., 2008] Paterno, F. Santoro, C., Mäntyjärvy, J., Mori, G., Sansone, S., Authoring pervasive multimodal user interfaces, Int. J. Web Engineering and Technology, Vol. 4.
No.2, pp. 235-243, 2008
[Prante et al., 2004] Prante, T., Streitz, N. A. and Tandler, P., Roomware: computers disappear
and interaction evolves, Computer, Vol. 37, No. 12, pp. 47-54, 2004.
[Pinelle et al, 2008] Pinelle, D., Stach, T. and Gutwin C., TableTrays: Temporary, reconfigurable work surfaces for tabletop groupware, Third IEEE International Workshop on Tabletops and Interactive Surfaces (Tabletop 2008), pp. 41-48, Amsterdam (The Netherlands),
2008.
[Raskin, 1994] Raskin, J., Intuitive Equals Familiar, Communications of the ACM, Vol. 37, No
9, pp. 17-18, September 1994.
[Rekimoto and Saitoh, 1999] Rekimoto J., Saitoh M., Augmented Surfaces: a Spatially Continuous Work Space for Hybrid Computing Environments, In Proceedings of Conference on
Human Factors in Computing Systems: The CHI is the Limit (CHI’1999), ACM Press, pp.
378-385, Pittsburgh PA (USA), May 15-20 1999.
178
REFERENCIAS
[Rekimoto, 1997] Rekimoto, J., Pick and Drop: A Direct Manipulation Technique for Multiple
Computer Environments. In Proc. of UIST97, ACM Press, pp. 31-39, 1997.
[Romero et al., 2013] Romero, M., Mendoza, S., Sánchez, G., A framework for developing
context-aware applications for co-located collaborative work, CCE, México, D.F. (México),
September 30 - October-4, 2013.
[Secretan et al., 2008] Secretan, J., Beato, N., D’Ambrosio, D., Rodriguez, A., Campbell, A.
and Stanley, K.,Picbreeder: evolving pictures collaboratively online, Proceedings of the
twenty-sixth annual SIGCHI conference on Human factors in computing systems, pp. 17591768. Florence (Italy), 2008
[Sendin et al., 2008] Sendin, M., López-Jaquero, V., Collazos, C. A., Collaborative Explicit
Plasticity Framework: a Conceptual Scheme for the Generation of Plastic and Group-Aware
User Interfaces , Journal of Universal Computer Science, Vol. 14, No. 9, pp. 1447-1462, 2008.
[Sendı́n and Collazos, 2006] Sendı́n, M. and Collazos, C. A., Implicit Plasticity Framework: A
Client-Side Generic Framework for Collaborative Activities., Y. A. Dimitriadis, I. Zigurs
and E. Gómez-Sánchez (Eds), CRIWG, pp. 219-227, 2006.
[Sendı́n and Lorés, 2004] Sendı́n, M. and Lorés, J., Plasticity in mobile devices: a dichotomic
and semantic view, Workshop Engineering Adaptive Web, pp. 58-67, 2004.
[Serafini and Bouquet, 2004] Serafini, L. and Bouquet, P., Comparing formal theories of context
in AI, Artificial Intelligence, Vol. 155, pp. 41-67, Elsevier Science Publishers Ltd, May 2004.
[Sohlenkamp et al., 2000] Sohlenkamp, M., Mambrey, P., Prinz, W., Fuchs, L., A. Syri,
Pankoke-Babatz, U., Klöckner, K., Kolvenbach, S.,Supporting the Distributed German Government with POLITeam, Multimedia Tools and Applications, Vol. 12, No.1, pp. 39-58,
2000.
[Stan et al., 2008] Stan, J., Egyed-zsigmond, E., Joly A. and Maret P., A User profiles Ontology
for Situation-Aware Social Networking, 3rd Workshop on Artificial Intelligence Techniques
for Ambient Intelligence (AITAmI2008), Augusto, J., Shapiro, D. and Aghajan H. (Eds.),pp.
1-5, Patras (Greece), 2008.
[Stanciulescu et al., 2005] Stanciulescu, A., Limbourg, Q., Vanderdonckt, J., Michotte, B.,
and Montero, F. A transformational approach for multimodal web user interfaces based
on UsiXML, In ICMI ’05: Proceedings of the 7th international conference on Multimodal
interfaces, pp. 259-266, 2005.
[Streitz et al., 1999] Streitz, N., Geibler, J., Holmer, T., Konomi, S., Möller-Tomfelde, C.,
Reischl, W., Rexroth, P., Seitz, P., Steinmetz, R. i-LAND: An interactive Landscape for
Creativity and Innovation, In Proc. of the ACM conf. On Human Factors in Computer
Human Interaction (CHI99), ACM, pp. 120-127, 1999.
REFERENCIAS
179
[Tandler et al., 2001] Tandler, P., Prante, T., Müller-Tomfelde C., Streitz, N., and Steinmetz,
R., Connectables: dynamic coupling of displays for the flexible creation of shared workspaces,
UIST 2001: Proceedings of the 14th annual ACM symposium on User interface software
and technology, ACM, pp. 11-20, New York, NY (USA), 2001.
[Thevenin and Coutaz, 1999] D. Thevenin and J. Coutaz, Plasticity of User Interfaces:Framework and Research Agenda, In Proceedings of Interact’99, vol. 1, Edinburgh:
IFIP, IOS Press, pp. 110-117, 1999.
[Vanderdonckt, et al., 2008] Vanderdonckt, J., Calvary, G., Coutaz, J., and Stanciulescu, A.,
Chapter 4: Multimodality for Plastic User Interfaces: Models, Methods, and Principles,
Multimodal User Interfaces, Signals and Communication Technology Series, pp. 61-84,
Springer, Berlin-Heidelberg (Germany), 2008.
[Vanderdonckt and González-Calleros, 2008] Vanderdonckt, J. and González-Calleros, J.,
Task-Driven Plasticity: One Step Forward with UbiDraw, pp. 181-196, In Proc. of the 2nd
Conference on Human-Centered Software Engineering and 7th International Workshop on
Task Models and Diagrams, Springer-Verlag LNCS 5247, Pisa (Italy), 2008.
[Wei et al., 2009] Wei, R., Zhang, R., Zhao C., Yue. D. and Li, L., Design and implementation
of scientific collaborative editing environment on chemistry, Eighth International Conference
on Grid and Cooperative Computing (GCC),pp. 188-92, Lanzhou, Gansu (China), 2009.
[Yongwu and Haake, 1999] Yongwu, M. and Haake, J., Supporting Concurrent Design in
SCOPE, In The International Journal of Concurrent Engineering Research and Applications, Vol. 7, No. 1, pp. 55-65, Technomic Publishing Co., Inc., March 1999.

XARE: Marco de desarrollo para sistemas colaborativos conscientes

Transcripción

Documentos relacionados

Razones para implementar un programa de

XARE: Marco de desarrollo para sistemas colaborativos conscientes