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
Directores 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 humano-computadora
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 simultáneamente varios dispositivos de cómputo, con el fin de satisfacer sus
necesidades. Esta variedad de dispositivos fijos y móviles (e.g., pizarrones electrónicos, tablets
digitales, PDAs y teléfonos inteligentes) impone nuevos requerimientos a las aplicaciones, como
la propiedad de adaptarse a cambios contextuales. Esta propiedad ha sido principalmente explorada en sistemas mono-usuario, generando la identificación de siete dimensiones entre las
que destaca el contexto de uso definido en términos del usuario, de la plataforma y del entorno. Es sabido que la creación de aplicaciones mediante un marco de desarrollo permite
que dichas aplicaciones adquieran “fácilmente” algunas de las caracterı́sticas definidas en el
marco. Los pocos marcos de desarrollo, enfocados en adaptar a los sistemas colaborativos a
cambios contextuales, han tomado algunas de las siete dimensiones diseñadas para los sistemas
mono-usuarios sin realizar ninguna modificación sobre estas. La contribución de este trabajo de
investigación se enfoca en dos aspectos principales. El primero provee la definición de contexto
de uso de los sistemas colaborativos, la cual incluye el grupo de colaboradores, el conjunto
de dispositivos en uso, ası́ como el entorno compartido, el cual puede ser fı́sico o virtual, e.g.,
documentos electrónicos. El segundo aspecto involucra la creación de un marco de desarrollo
llamado XARE (conteXt-Aware groupwaRE) que facilita la creación de sistemas colaborativos
sensibles al contexto, considerando cinco de las siete dimensiones previamente mencionadas.
Este marco está acompañado por un conjunto de clases y mecanismos y fue creado a partir
de un conjunto de escenarios y aplicaciones que nos permitieron expresar diversos tipos de
adaptaciones.
Palabras claves: Plasticidad de las interfaces de usuario, contexto de uso, remodelación
de las interfaces de usuario, Interacción Humano-Computadora, sistemas colaborativos, marcos
plásticos.
iv
Abstract
Currently, most of the applications assume that human-computer interaction is confined to a
single computing device (e.g., a PC) where the user employs traditional input/output devices
(e.g, monitor, keyboard and mouse). However, the increasing proliferation of computing devices
and the progress of communication networks potentially transform the user into an entity
that operates in a changing environment and simultaneously uses various computer devices
in order to satisfy his needs. This variety of stationary and mobile devices (e.g., electronic
whiteboards, tablets, PDAs and smartphones) imposes new requirements on applications such
as the capacity to adapt themselves to contextual changes. Adaptability has been mainly
explored in single-user systems, leading to the identification of seven dimensions, among which
the context of use defined in terms of the user, platform and environment is highlighted. It is
known that the creation of applications using a development framework allows such applications
to acquire some of the features defined in the framework. The few development frameworks
focused on adapting groupware systems to contextual changes have taken some of the seven
dimensions designed for single-user systems without applying any modification on them. The
contribution of this research work is focused on two main aspects. The former one provides the
definition of the context of use for groupware systems by including the group of collaborators,
the set of devices in use and the shared environment, which can be physical or virtual, e.g,
electronic documents. The latter aspect refers to the creation of a development framework called
XARE (conteXt-Aware groupwaRE) that facilitates the creation of context-aware groupware
systems by considering five of the seven dimensions previously mentioned. This framework is
accompanied by a set of classes and mechanisms and was created from a set scenarios and
applications that allowed us to express several types of adaptations.
Key words: plasticity of user interfaces, context of use, remodelation of user interfaces,
human-interaction computer, collaborative systems, plastic frameworks.
v
Agradecimientos
CONACYT y CINVESTAV:
Gracias por su apoyo para la realización de esta tesis.
Dra. Sonia G. Mendoza y Dr.
Dominique Decouchant: Gracias por su confianza, paciencia,
apoyo y comprensión en el desarrollo de esta tesis.
Mami: Gracias por ser la mamá
que eres, gracias por dedicarnos
tu vida a mi y a mis hermanos. Gracias por ser fuerte
como un padre y cariñosa como
una madre. Gracias por continuar luchando dı́a a dı́a. Te amo
Chinitos.
A mis hermanos: Rosy y Dany
gracias por cuidarme desde los
primeros dı́as de mi vida. Rebe,
Aby y Maru gracias por apoyarme
en todo momento.
Gracias Pedro Miranda, Ivan M.
Romero, Laura Granados y Sandra B y a los chicos de colima
(Alex, y Gris) por su apoyo en la
realización de está tesis.
vi
Gracias Sofia, Erica y Felipa por
brindarme su comprensión, por
ser mis amigas cuando más las
necesite. Gracias José Luis, y Dr.
Santiago por su apoyo.
Creo que he visto un Baquero,
gracias por tus consejos Rafa.
Gracias Amilcar por todos los
consejos profesionales y personales que me has brindado todo
este tiempo.
Gracias Kim, Ivone, Cheche, Dr.
Guadalupe y mis compañeros del
CINVESTAV.
Gracias Gabriel, Lobatos y
Ernesto por escucharme, apoyarme y hacerme reir en todo
momento.
Gracias Saad por todo.
Gracias a todas las pesonas que
en algún momento compartieron
conmigo parte de está aventura en
el CINVESTAV.
vii
Dedicatoria
† Marı́a Eugenia Morales Aguilar
Esta tesis se la quiero dedicar a mi mamá, Marı́a Eugenia Morales Aguilar, por que ella fué y
ha sido un ejemplo a seguir, por que cada una de tus lecciones las llevaste a cabo, por ejemplo:
seguir en pie frente a la vida sin importar las adversidades, ya que hasta el último dı́a de tu
vida tú luchaste.
Recuerdo que cuando eramos pequeños mis hermanos y yo solias contarnos cuentos antes de
dormir, la mayorı́a train moraleja, incluso muchos de esos cuentos los cambiabas tú para que
nos dieras una lección de vida.
Se que si hubieses vivido más tiempo me hubieses enseñado más cosas, pero era tiempo que
te fueras y te agradezco todo el tiempo que me diste, espero yo algún dı́a ser como tú.
Tú sabes el esfuerzo que hubo detrás de está tesis, por eso quiero dedicartela. Te amo mamá,
yo sé que estas palabras las escuchaste muchas veces, pero no me cansaré de decirlas aún cuando
ya no estes aquı́.
viii
Índice general
Índice de figuras
ix
Índice de tablas
xi
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
ix
x
ÍNDICE GENERAL
2.6 Cobertura del contexto de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.7 Cobertura de espacio tecnológico . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.8 Meta-interfaz de usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.10 Sı́ntesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
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 Explı́cita 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 Sı́ntesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
ÍNDICE GENERAL
4 Análisis de requerimientos del marco XARE
xi
73
4.1 Contexto de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.1.1
Contexto de uso de los sistemas mono-usuario . . . . . . . . . . . . . . . 74
4.1.2
Contexto de uso de los sistemas colaborativos . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
4.4 Escenario 2: Remodelación de la interfaz de usuario . . . . . . . . . . . . . . . . 89
4.4.1
Preámbulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
4.4.2
4.4.3
Editor de mapas mentales . . . . . . . . . . . . . . . . . . . . . . . . . . 93
4.5 Escenario 3: Redistribución de una aplicación colaborativa . . . . . . . . . . . . 97
4.5.1
Preámbulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
4.5.2
4.5.3
Herramienta de votación . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
4.6 Escenario 4: Mejoramiento de la conciencia grupal . . . . . . . . . . . . . . . . . 106
4.6.1
Preámbulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
4.6.2
4.6.3
Herramienta disponibilidad y medios de contacto . . . . . . . . . . . . . 111
4.7 Escenario 5: Manejo de intromisiones . . . . . . . . . . . . . . . . . . . . . . . . 113
4.7.1
Preámbulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
4.7.2
4.8 Escenario 6: Suministro de información relevante . . . . . . . . . . . . . . . . . 115
4.8.1
Preámbulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
4.8.2
xii
ÍNDICE GENERAL
4.8.3
Herramienta administrador de contenidos vı́a NFC . . . . . . . . . . . . 118
4.9 Escenario 7: Notificaciones multi-modales
. . . . . . . . . . . . . . . . . . . . . 120
4.9.1
Preámbulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
4.9.2
4.10 Sı́ntesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
5 Diseño del marco XARE
125
5.1 Diagramas de clases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
5.1.1
Contexto de uso de los sistemas colaborativos . . . . . . . . . . . . . . . 126
5.1.2
Componente observador . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
5.2 Mecanismos del marco XARE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
5.2.1
Mecanismo de similitud de actividades . . . . . . . . . . . . . . . . . . . 134
5.2.2
Mecanismo de disponibilidad de un colaborador . . . . . . . . . . . . . . 136
5.2.3
Mecanismo de medios de contacto . . . . . . . . . . . . . . . . . . . . . . 138
5.2.4
Mecanismo de ocultar, sustituir y mostrar componentes . . . . . . . . . . 140
5.2.5
Mecanismo para la creación de referencias deı́cticas . . . . . . . . . . . . 141
5.2.6
Mecanismo de proximidad lógica . . . . . . . . . . . . . . . . . . . . . . 143
5.2.7
Mecanismo ubicación fı́sica . . . . . . . . . . . . . . . . . . . . . . . . . . 145
5.3 Marco XARE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
5.4 Sı́ntesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
6 Funcionamiento del marco XARE
153
6.1 Instancias del marco XARE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
6.2 API de comunicación entre las capas . . . . . . . . . . . . . . . . . . . . . . . . 155
6.3 Sı́ntesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
7 Conclusiones y trabajo a futuro
163
7.1 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
7.2 Trabajo a futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
ÍNDICE GENERAL
xiii
A Publicaciones
171
Referencias
173
xiv
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
xv
xvi
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 . . . . . . . . . . . . 37
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.7 Arquitectura conceptual del Marco Genérico de Contexto . . . . . . . . . . . . . 64
4.1 Relación entre escenarios y aplicaciones colaborativas . . . . . . . . . . . . . . . 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 mensajerı́a instantánea para referirse a un
párrafo mostrado 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 mensajerı́a instantánea para referirse a una figura
mostrada en el editor colaborativo . . . . . . . . . . . . . . . . . . . . . . . . . . 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
xvii
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 Pantalla principal donde se muestran las aplicaciones disponibles y una barra de
colaboradores que exhibe a los miembros ausentes y virtualmente presentes . . . 91
4.7 Pantalla para elegir a los participantes en la creación del mapa mental y sus roles 92
4.8 Vista del mapa mental cuando un colaborador asume el rol de revisor . . . . . . 93
4.9 Vista del mapa mental cuando un colaborador asume el rol de autor . . . . . . . 94
4.10 Adaptabilidad de la interfaz de usuario del editor colaborativo de mapas mentales
con base en la configuración del grupo, las dimensiones de la pantalla y el rol del
usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
4.11 Datos de la votación en curso ingresados por el proponente en el pizarrón interactivo 99
4.12 Adaptabilidad de la interfaz de usuario de la herramienta de votación con base
en la configuración del grupo y el rol del usuario . . . . . . . . . . . . . . . . . . 101
4.13 Resultados de la votación mostrados a los participantes co-localizados en el
pizarrón interactivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
4.14 Resultados de la votación mostrados en los dispositivos de los participantes distribuidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
4.15 Disponibilidad y medios de contacto al inicio de la sesión colaborativa. . . . . . 109
4.16 Disponibilidad y medios de contacto de Sandy, Isaac y Alice una vez que Sandy
ha cambiado su actividad. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
5.1 Contexto de uso de los sistemas colaborativos . . . . . . . . . . . . . . . . . . . 127
5.2 Diagrama de clases del componente observador . . . . . . . . . . . . . . . . . . . 131
5.3 Mecanismo para determinar los medios de contacto de un colaborador . . . . . . 139
5.4 Mecanismo para ocultar, sustituir o mostrar componentes y/o funcionalidades . 141
5.5 Mecanismo de referencias deı́ticas . . . . . . . . . . . . . . . . . . . . . . . . . . 142
5.6 Visualización de documentos en forma de árbol . . . . . . . . . . . . . . . . . . 144
5.7 Mecanismo de ubicación fı́sica . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
5.8 Capas del marco XARE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
6.1 Instancias del marco XARE en los dispositivos móviles . . . . . . . . . . . . . . 154
xviii
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 Similitud entre las actividades de dos colaboradores . . . . . . . . . . . . . . . . 135
5.2 Estados de disponibilidad de un colaborador percibidos por sus colegas . . . . . 137
5.3 Proximidad lógica entre dos colaboradores en un espacio de trabajo compartido 145
5.4 Sugerencias de mecanismos para implementar las aplicaciones de algunos escenarios analizados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
6.1 API de la comunicación entre instancias del marco XARE . . . . . . . . . . . . 155
6.2 API de la capa de espacio de trabajo . . . . . . . . . . . . . . . . . . . . . . . . 156
6.3 API de la capa de adaptación . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
6.4 API de la capa de detección . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
xix
xx
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
en múltiples dispositivos heterogéneos. La propiedad de “plasticidad” pretende hacer frente a
8
Introducción
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
del contexto de uso (i.e., usuario, entorno y plataforma), sólo unos cuantos consideran alguna
Capı́tulo 1
9
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.
Dado el planteamiento del problema podemos generar la siguiente hipótesis:
Es posible definir un contexto de uso para los sistemas colaborativos que considere las caracterı́sticas propias de los entornos colaborativos, ası́ como crear un marco que facilite la creación
de sistemas colaborativos capaces de adaptarse a cambios contextuales.
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
de usuario plásticas. La mayorı́a de estos escenarios son ejemplificados mediante aplicaciones.
12
Introducción
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 una sı́ntesis 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
pared, que forman un dispositivo largo y sensible al contacto. InteracTable es una pantalla
16
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
dinámico significa que la remodelación y la redistribución se pueden realizar en tiempo de
ejecución [Vanderdonckt, et al., 2008].
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
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.
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,
32
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]).
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).
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
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]).
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
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.
En los sistemas analizados podemos observar que ninguno se adapta al entorno.
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
Capı́tulo 2
35
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
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
36
Dos o mas teléfonos celulares forman un
espacio
Figura 2.25: Adaptación a la plataforma en el sistema MindMap
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]—,
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
Capı́tulo 2
37
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.
Meta-IU
Figura 2.26: Meta-IU con negociación en el sitio Web de Sedan-Bouillon
38
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
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.
Capı́tulo 2
39
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
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.
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
40
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
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
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.
2.10
Sı́ntesis
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
Capı́tulo 2
41
Sistema
Variables contextuales
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
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.
42
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 la meta interfaz de usuario
y algunos percutores de plasticidad 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 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.
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
una sı́ntesis 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 (O4)
Evolución (O6)
Configuración
2
Tareas
(I2)
Plataforma
(I4)
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
de los modelos de evolución y transición. El modelo de evolución (O6) indica a
los sistemas interactivos cuándo deben adaptarse a cambios de contexto, mientras que el
modelo de transición (O7) tiene como objetivo suavizar discontinuidades entre dichos
cambios.
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 los modelos 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 tareas.
1
Es una notación gráfica que sirve para describir el modelo de tareas [Paterno and Mancini, 1997].
46
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 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 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 (IU
Final). 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 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 de “regular”
a “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., pasar 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).
Los modelos observadores conducen la adaptación en tiempo de ejecución. Tanto los mod-
Capı́tulo 3
47
elos ontológicos Oj como los 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 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
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
48
Modelos
Herramienta
PetShop
Ontológicos
O1-O7,
ractoresa
Inte-
Arquetı́picos
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 considera esta componente, pero la herramienta no
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 asociación de los métodos con los eventos, e.g., despliegue de un menú mediante
un clic derecho sobre un avión y c) la respuesta 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),
tareas (I2) y plataforma (I4). La metodologı́a TERESA recomienda empezar por hacer
descripciones de las tareas, e.g., “apagar la luz”.
Los modelos transitorios corresponden al modelo de tareas y 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 aplicación.
La IU abstracta es generada mediante los modelos de presentación y diálogo.
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, diálogo,
plataforma y dispositivos. En esta herramienta no se incluye el modelo de tareas debido
Capı́tulo 3
49
a que las tareas de un usuario no cambian durante el proceso de adaptación.
TERESA genera modelo de conceptos y 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, diálogo y 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 interfaz de usuario,
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 la 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 redistribució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 del usuario [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.
La capa de plataforma incluye tanto el hardware como el sistema operativo. El hardware
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
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).
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
Capı́tulo 3
51
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
componentes, estos son recuperados del espacio de almacenamiento por el administrador
de componentes.
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
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: 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, I-AM 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] tiene 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
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.
Capı́tulo 3
53
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 Explı́cita Colaborativa
Sendin et al. proponen un marco conceptual llamado Plasticidad Explı́cita Colaborativa (PEC)
[Sendı́n and Lorés, 2004]. El término de “plasticidad explı́cita” se refiere a la capacidad de
generar automáticamente una interfaz de usuario especı́fica para un contexto de uso, empezando de una especificación abstracta. Para lograr la generación automática de dicha interfaz se requiere de una máquina EPE (Explicity Plasticity Engine) en la etapa de diseño
[Sendı́n and Collazos, 2006].
El marco PEC se ubica del lado del servidor para llevar a cabo las adaptaciones necesarias
cuando un cliente haya iniciado una sesión o solicite una nueva adaptación. Dicho 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
54
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., dialogo,
tarea, dominio y espacial. La fase ARP genera la Interfaz de Usuario Abstracta (IU
abstracta) usando los siguientes modelos: tarea, dominio, espacial, usuario, dialogo y
grupo. La fase CRP obtiene la Interfaz de Usuario Concreta (IU concreta) a partir de
la IU abstracta; ésta fase selecciona los componentes concretos de la interfaz de usuario que
mejor representa 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):
• Modelo de tarea: es una representación estructurada de las tareas que un usuario puede
llevar a cabo mediante una interfaz de usuario;
• Modelo de dominio: denota los objetos relacionados con la tarea de un usuario;
• Modelo de usuario: representa las caracterı́sticas y los aspectos relacionados con un
usuario, tales como el nivel de conocimiento, preferencias, objetivos, situación, necesidades, etc.;
• Modelo de dialogo: 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;
• Modelo espacial: es una descripción detallada del mundo real que proporciona conciencia de ubicación;
• Modelo de plataforma: se 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);
• Modelo de entorno: 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;
• Modelo de grupo: 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).
Capı́tulo 3
55
Figura 3.3: Marco conceptual de Plasticidad Explicita Colaborativa
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. IU abstracta : 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;
2. IU concreta: 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
56
IU abstracta;
3. IU final: es generada a partir de la IU concreta, 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 IU final es IMP (cf.
Figura 3.3) ya que transforma el aspecto visual y dinámico de la IU concreta 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 IU abstracta a la IU concreta . 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:
• Modelo de tarea: usa tres diferentes notaciones, tales como diagrama de estado, modelo
CTT, además de una herramienta de interacción abstracta;
• IU abstracta: usa UMLi (Unified Modeling Language for Interactive Applications);
• IU concreta: usa UsiXML (User Interface eXtensible Markup Language);
• IU final : es realizada por un traductor;
• Criterio de usabilidad: 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
de las organizaciones, los despliegues públicos se han utilizado para facilitar las tareas, la
Capı́tulo 3
57
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 explı́citas 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), enriquecimiento de la
presencia (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 detección facial. Una vez obtenida la caracterización, se puede aplicar algún patrón de
58
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
su interés respecto a un deporte, entonces el sistema podrı́a mostrar el contenido relacionado
Capı́tulo 3
59
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 explı́cita.
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 para modo tanto individual como grupal. 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. utilizan
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 considera información externa a las
circunstancias (e.g, tiempo y lugar) e 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 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.
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
60
clic sobre un ı́cono. Esta clase está ubicada en el servidor y recibe notificaciones, por parte de
cada cliente, acerca de algún cambio en el estado actual del usuario correspondiente, 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, lo cual implica que el servidor solicite información
de estado a 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 algunas operaciones de inferencia en el servidor .
La clase MecanismoDeSensado infiere información de 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 y globales y
opcionalmente guarda el contexto del grupo. En el caso de los estados globales, el repositorio
podrı́a usar sentencias para representar el estado de un grupo. Dichos datos se guardan en 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
ilustrar algunas recomendaciones. Dicho ejemplo puede ser reemplazado 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 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., el uso de un filtro colaborativo para obtener ciertos elementos, los cuales
pueden utilizarse como mecanismos 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
RecFlow. Dicha librerı́a es una implementación de la interfaz FlujoDeTrabajo, pero no se
reporta el desarrollo de alguna aplicación especı́fica.
Capı́tulo 3
3.7
61
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 este marco cubre aspectos individuales como grupales. 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: conocimiento, estado, contextualización y
adaptación (cf. Figura 3.6).
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
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
62
aspectos del 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., la idea de
que una persona está en un cuarto (conocimiento abstracto), se deriva del hecho que Paúl
está en el cuarto LF283 (conocimiento concreto). Las reglas de inferencia se encargan
de hacer la extracción 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 (e.g., texto, imagen y
calendario).
La capa de estado contiene información de la situación actual, del entorno fı́sico y computacional, de los recursos y del usuario, e.g., ¿En dónde está el usuario? ¿Qué hora es? y
¿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, i. e., 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 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.
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́
Capı́tulo 3
63
acción de adaptación se ejecuta en qué caso. Las reglas de adaptación incluyen operaciones
para cambiar propiedades del entorno colaborativo 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,
espacios de trabajo, tareas a resolver, actividades de los colaboradores y aplicaciones colaborativas.
Por otro lado los escenarios, representados por medio del lenguaje OWL (Web Ontology
Language), están divididos respecto a situaciones colaborativas tales como co-localización, coacceso, 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 los participantes que están
co-localizados como los dispositivos en uso (co-localización); la habilitación de funcionalidades
en un sistema colaborativo con base en 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. En particular, el proceso de adaptación del marco CG se puede representar 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 tiene como entrada el modelo de estado (capa de estado),
el cual es procesado por las reglas de contextualización, cuya tarea es establecer el
estado de contextualización (capa de contextualización);
• 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.
64
El marco GC permite extender las aplicaciones colaborativas con propiedades adaptativas.
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 a cambios contextuales. 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 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
Otro módulo importante 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, reglas de sensado y el modelo de estado.
En la arquitectura propuesta se debe habilitar primero el mecanismo de adaptación para
Capı́tulo 3
65
permitir cambios en las IU de la aplicación por medio del componente de adaptación.
Dicho componente llama a las 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 activa
el mecanismo de sensado para monitorear la interacción entre el usuario y 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 en 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. 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 plugin 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 espacios de trabajo como documentos, además de proveer
conciencia ası́ncrona y comunicación. Los servicios básicos se refieren al acceso del usuario,
a la administración de la 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. Aunque no crearon una aplicación especı́fica, realizaron pruebas funcionales a partir de cuatro escenarios relevantes que denotan situaciones tı́picas del trabajo
colaborativo (co-localización, co-acceso, co-recomendación y co-dependencia).
3.8
Análisis comparativo de los marcos analizados
En la Tabla 3.2 se analizan dos caracterı́sticas importantes de los marcos revisados. La primera
es conocer si los marcos están diseñados para desarrollar sistemas mono-usuario o colaborativos.
En este caso se aprecia que tanto el marco RUIUM-O4 como CAMELEON-RT se enfocan en
sistemas mono-usuario. En cambio, los marcos restantes (PI5 , PEC6 , ACCDP7 , RCCG8 y GC9 )
se especializan en sistemas colaborativos; el marco PI tiene como objetivo ofrecer plasticidad
y conciencia de grupo a los sistemas colaborativos, mientras que 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, lo cuales dan soporte al trabajo
3
http://r-osgi.sourceforge.net/
Referencia Unificado para Interfaces de Usuario Multi-Objetivo
5
Plasticidad Implı́cita
6
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
4
66
colaborativo.
Marco conceptual
Colaborativo
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 tanto individual como grupal, ya que el primero tiene como objetivo
proveer recomendaciones en ambos ámbitos, en tanto que el marco GC puede ayudar a formar
un contexto grupal a partir de aspectos individuales, e.g., determinar la ubicación de cada
usuario.
La segunda caracterı́stica importante mostrada en la Tabla 3.2 se refiere a conocer si los
marcos ofrecen algún tipo de implementación. El marco RUIUM-O no implementa ningún
ejemplo de prueba, sino que se probó al compararse con algunas herramientas, que siguen una
metodologı́a similar 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 para sistemas
colaborativos, el marco PI se encuentra en vı́as de implementación, hasta el momento se encuentra en desarrollo la parte del servidor. Bajo el marco PEC se reporta la herramienta AB-UIED
que permite la producción automática de interfaces plásticas, para entornos mono-usuario ya
que no se implementaron los módulos concernientes al soporte de la colaboración, e.g., el modelo de grupo. Es importante hacer notar que no se reporta ninguna aplicación desarrollada
mediante la herramienta AB-UIED.
El marco RCCG ofrece librerı́as y algunos algoritmos para proveer la recomendación de
conciencia de contexto, solo que no se reporta ninguna aplicación que haga uso de dichas
librerı́as. Por otro lado, Haake et al., autores del marco GC, implementaron la arquitectura
Capı́tulo 3
67
propuesta para unir el marco GC con aplicaciones colaborativas. A partir de los escenarios
reportados, obtienen pruebas funcionales, las cuales son usadas para probar la implementación
de la arquitectura.
Por otra parte, como se mencionó en el capı́tulo 2, 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 dimensiones que conforman dicho
espacio del problema.
Una de las siete dimesiones 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 a la
plataforma sin perder un conjunto de criterios de calidad, e.g., la 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 los modelos ontológicos como en los arquetı́picos; en este marco se considera
al usuario de manera general en sus modelos de usuario, ubicado en los modelos ontológicos y
arquetı́picos; además podemos observar que existe el modelo de tareas para referirse a la tarea
del usuario. En cambio, el modelo de plataforma permite hacer la descripción de los dispositivos
disponibles, ası́ como clasificarlos en plataforma básica, e.g, computadora personal, o en clusters.
El modelo de entorno contiene 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, al entorno y a 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 y 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. Este marco también 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 provee información relevante, e.g., perfil del usuario, su ubicación y su posición relativa.
El marco PEC considera por completo el contexto de uso, ya que representa al usuario
mediante varios modelos, e.g., usuario, dominio y tarea, para tener conocimiento de sus caracterı́sticas, e.g., conjunto de tareas que puede llevar a cabo, preferencias, objetivos, nivel de
conocimiento, situaciones y necesidades. El marco PEC aborda la plataforma por medio del
modelo de plataforma para contabilizar los recursos fı́sicos, ası́ como las caracterı́sticas de software. Finalmente, el marco mencionado contempla al entorno mediante el modelo espacial y
el de ambiente para obtener la descripción del exterior, de tal manera que se pueda crear una
conciencia de ubicación, tiempo (hora y dı́a de la semana) y condiciones ambientales (luz del
dı́a, nivel de ruido ambiental y condiciones 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
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
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
Capı́tulo 3
69
las reglas de contextualización (capa de contextualización); el artefacto que los colaboradores
están manipulando en un momento dado, la formación de grupos, varios aspectos de la tarea,
tales como la tarea a resolver, las prioridades entre ellas, el tiempo lı́mite, la dependencia
entre ellas y la asignación automática o manual; el rol y aspectos dependientes del rol, como
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 los participantes, tiempo (hora actual), co-localización, y las acciones
permitidas en las aplicaciones con base en el rol.
Tanto el marco ACCDP como el marco RCCG abordan parcialmente el contexto de uso,
ya que no incluyen a 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,
la identificación y el enriquecimiento de la presencia. Por su parte, el marco RCCG considera
el estado del usuario mediante las clases AdministradorDeEstado, MecanismoDeSensado, entre
otras para inferir la ubicación o conocer el elemento de la interfaz de usuario que ha sido
seleccionado. El entorno es abordado por el marco ACCDP, ya que puede detectar la cantidad
de personas en un lugar, el género, etc, ası́ como la sugerencia de contenido de un grupo
mediante la caracterización de huellas digitales y sugerencia de contenido. El marco ACCDP
aborda el entorno cuando proporciona el trabajo a miembros de un 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 la interfaz de usuario, e.g., nivel de luz.
El resto de las dimensiones del espacio del problema corresponden a percutores
de plasticidad, granularidad de adaptación, 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 el modelo de evolución;
por lo tanto podemos decir que este marco implementa la migración, pero no especifica si
implementa la remodelación o la redistribución. Por otro lado, el marco CAMELEON-RT
implementa parcialmente el percutor de plasticidad mediante su capa middleware, la cual
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 mediante
remodelación, redistribución o migración.
La granularidad de la interfaz de usuario señala el grado en el que la interfaz de
usuario ha sido modificada 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.
70
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 ejemplifica a nivel de tarea. Aún cuando el marco PEC no especı́fica la
implementación de dicha granularidad, considera almacenar información de cada miembro. El
resto de los marcos, CAMELEON-RT, PI, ACCDP, RCCG y GC, no proporcionan indicios de
soportar la granularidad del estado de recuperación.
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 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; 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. La mayorı́a de 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; el marco RUIUM-O considera el
cambio de código ejecutable cuando este 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) muestra 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, este considera la Meta-IU con negociación, ya que el desarrollador puede intervenir en la adaptación de 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
de diálogo para establecer 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, tipo de contexto y variables contextuales.
El tipo de adaptación está conformado por la presentación de información, la ejecución
automática de un servicio y la información aumentada. Los marcos RUIUM-O, PI, PEC,
RCCG y GC no especifican qué tipo de adaptación llevan a acabo, ya que esta tarea queda
a cargo del 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
Capı́tulo 3
71
Marco
ceptual
con-
Tipo de contexto
Variables
textuales
mono-entidad
contexto
CAMELEONejecución
RT
mono-entidad
plataforma
PI
no especifica
multi-entidad
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
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
de la interfaz de usuario. El marco ACCDP proporciona ejemplos de adaptaciones, los cuales
cubren dos tipos de adaptación, la primera corresponde a la presentación de información cuando
se siguiere mostrar información relevante a un grupo; la segunda se refiere a la información
aumentada al mostrar información de interés en un lugar especı́fico.
El tipo de contexto se refiere a considerar una sola entidad, mono-entidad, o a considerar varias entidades de forma simultanea, multi-entidad. Aún cuando los marcos RUIUM-O
y CAMELEON-RT consideran múltiples variables contextuales, e.g., plataforma, entorno y
tareas, dichos marcos son mono-entidad, ya que se centran 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 individual y grupal. Por su parte, 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.
72
Las variables contextuales son las 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 a la plataforma, pues a partir de la
detección de una plataforma la interfaz de usuario puede migrar o redistribuirse. En cambio,
el marco PEC realiza la adaptación de dos manera; la primera ocurre al genera la IU inicial y
la segunda adaptación ocurre cuando el cliente solicita la adaptación. El marco ACCDP lleva
a cabo la adaptación cuando ocurre un cambio en algunas de las huellas digitales siguientes:
presencia, enriquecimiento de la presencia, 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
Sı́ntesis
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 una
tendencia en considerar varias peculiaridades del usuario, e.g., el perfil y las preferencias, con
la finalidad de proveer una mejor adaptación de la interfaz de usuario. Estas caracterı́sticas
contemplan ciertas acciones en especı́fico, e.g., detectar 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 aspecto es utiliza 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 a 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-interfaz de usuario, ası́ como llevar a cabo la adaptación del sistema en tiempo de
ejecución, dejando de lado las dimensiones.
Capı́tulo 4
Análisis de requerimientos del marco
XARE
En este capı́tulo se presenta una recapitulació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 mencionados 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 por estos procesos adaptativos, se proponen varias aplicaciones,
algunas de las cuales son reutilizadas en varios de dichos escenarios (cf. Sección 4.2).
Cada escenario está estructurado en dos partes: 1) un preámbulo y 2) una descripción detallada. La primera parte explica brevemente las posibles adaptaciones contextuales de las
aplicaciones encargadas de automatizar parcial o completamente algún proceso de trabajo colaborativo, mientras que la segunda parte ejemplifica el ámbito del escenario y pone en evidencia
los diferentes contextos de uso de las aplicaciones colaborativas involucradas, las cuales fueron
generadas a partir de un conjunto de requerimientos funcionales y no funcionales (cf. Sección
4.3-4.9).
Finalmente, se presentan una sı́ntesis derivada de este capı́tulo (cf. Sección 6.3).
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
Humano-Computadora (IHM), tales como la capacidad de los sistemas interactivos para ejecutarse en diferentes contextos de uso. Probablemente la definición de contexto más referenciada
73
74
Análisis de requerimientos del marco XARE
es la que proponen Dey et. al, la cual dice [Dey et al., 2001]:
“Contexto es cualquier 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
una aplicación, incluyendo al propio usuario y a dicha aplicación.”
4.1.1
Contexto de uso de los sistemas mono-usuario
Como se mencionó en el capı́tulo 1, la plasticidad de interfaces de usuario en el dominio de los
sistemas mono-usuario [Calvary et al., 2006] se define como:
“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 y la
continuidad de interacción”.
Por contexto de uso se entiende la terna <usuario, plataforma, entorno> donde el componente usuario denota el arquetipo humano que tiene por objeto utilizar el sistema interactivo
[Vanderdonckt, et al., 2008]. Este componente comprende varios elementos: perfil, actividad
[Coutaz and Calvary, 2008] y rol, los cuales actúan como factores externos al sistema que depende del usuario y que 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 analizados en conjunto. Algunos estudios se han limitado a 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 del 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],
o permitir a los usuarios decidir la manera en que desean ser contactados, dada una situación
determinada [Stan et al., 2008].
El componente 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 los medios
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., 2001, Calvary et al., 2004].
El componente 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
Capı́tulo 4
75
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., 2001, Calvary et al., 2004].
4.1.2
Contexto de uso de los sistemas colaborativos
El desarrollo de un espacio de interacción colaborativo puede resultar complejo, ya que se
deben considerar varios aspectos, e.g., las actividades de los colaboradores y la conciencia de
grupo. Dourish y Bellotti definen la 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 [Dourish and Bellotti, 1992,
Gutwin et al., 1995]:
• conciencia informal: permite conocer tanto la ubicación de los colaboradores como su
estado de disponibilidad;
• conciencia de grupo estructural: proporciona información de roles, responsabilidades,
posición social o profesional de los miembros de un grupo;
• conciencia social: permite el entendimiento del contexto tanto social como conversacional
de los colaboradores, y
• conciencia de espacio del trabajo: ofrece información sobre la interacción de los miembros
de un grupo en el espacio de trabajo 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 colaborativos. 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 alguna actividad.
El componente grupo de colaboradores denota los arquetipos humanos que utilizan el
sistema colaborativo para llevar a cabo un proyecto común.
El componente conjunto de plataformas se refiere a las caracterı́sticas de hardware y
software de los dispositivos de cómputo que alojan al sistema colaborativo 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 interactivo).
Este componente también incluye los dispositivos que permiten un mejor funcionamiento del
sistema colaborativo (e.g., impresoras y servidores).
76
El componente entorno común se refiere 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 colaborativo. Este componente también incluye
un entorno virtual, e.g., un desktop, los espacios de trabajo públicos y privados de aplicaciones
colaborativas y objetos compartidos. Un desktop se define como un conjunto de aplicaciones
disponibles para un colaborador dependiendo su rol [Haake et al., 2010]. Los objetos compartidos se refieren al texto, a las imágenes, al audio y al video que son compartidos por los
colaboradores a través del espacio de trabajo público de una aplicación colaborativa.
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 los requerimientos de algunas
aplicaciones colaborativas adaptables a cambios contextuales. A partir de estos requerimientos,
se crearon los diagramas de clase del marco XARE, los cuales serán presentadas en el capı́tulo
5.
Los cambios contextuales abordados en esta tesis se ponen en evidencia en siete escenarios
propuestos (cf. Figura 4.1). Algunos de ellos hacen referencia a aplicaciones computacionales,
cuyo objetivo es facilitar la colaboración entre los miembros de un grupo. En la figura 4.1, los
rectángulos que representan a los escenarios muestran diferentes colores (verde oliva, amarillo
y rosa) con el fin de denotar el grado de aportación al diseño del marco XARE. El color verde
oliva indica que se detectaron suficientes aplicaciones para automatizar el proceso colaborativo
descrito en el escenario; el color amarillo indica que las aplicaciones identificadas no aseguran
una automatización completa y finalmente, el color rosa significa que hasta el momento no se
han identificado aplicaciones especı́ficas.
Asimismo en la Figura 4.1, las aplicaciones también han sido representadas con diferentes
colores (azul, naranja y rojo) para denotar su estado de avance. El color azul representa a las
aplicaciones implementadas; el color verde denota a las aplicaciones en proceso de desarrollo y
por último el color rojo representa a las aplicaciones que no han sido implementadas.
Para lograr un mejor entendimiento de la Figura 4.1, primero se describen brevemente las
aplicaciones identificadas:
1. la barra de colaboradores [Romero et al., 2013] expresa la conciencia de grupo mediante
la foto y el nombre de los colaboradores pertenecientes a un equipo de trabajo. 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;
Capı́tulo 4
77
Escenario 2:
Remodelación de la
interfaz de usuario
Desktop
enriquecido
Herramienta de
votación
Editor de mapas
mentales
Escenario 3:
Redistribución
de una aplicación
colaborativa
Barra de
colaboradores
Aplicación implementada
Escenario 1:
Mejoramiento del
trabajo colaborativo
Editor de dibujos
Escenario 7:
Notificaciones multimodales
Administrador de
contenidos vía NFC
Escenario 6:
Suministro de
información relevante
Herramienta de
medios de contacto
y disponibilidad
Escenario 4:
Mejoramiento de la
conciencia grupal
Editor de textos
Escenario 5: Manejo
de intromisiones
Aplicación en proceso de desarrollo
Aplicación identificada pero no implementada
Escenario con suficientes aplicaciones para automatizar un proceso colaborativo
Escenario con insuficientes aplicaciones para automatizar un proceso colaborativo
Escenario carente de aplicaciones
Figura 4.1: Relación entre escenarios y aplicaciones colaborativas
3. el editor de mapas mentales [Romero et al., 2013] facilita la creación de diagramas para
organizar ideas;
4. el editor de dibujos tiene como objetivo permitir la creación de imágenes vectoriales y
tiene la caracterı́stica de soportar 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 interactivo) o un arreglo de tablets. Estas transiciones originan
que las funcionalidades de la aplicación se adapten para dar soporte a la interacción de
múltiples usuarios, considerando sus roles y sus jerarquı́as;
5. la herramienta de medios de contacto y disponibilidad [Decouchant, et al., 2013] presenta
de manera visual tanto la disponibilidad como los medios de contacto accesibles de un
78
colaborador, considerando varios parámetros, tanto del colaborador a contactar como del
que desea contactarlo;
6. la desktop enriquecido [Decouchant, et al., 2013] permite relacionar objetos manipulados
entre diferentes aplicaciones mediante referencias deı́cticas, las cuales son capaces de
mantener, en todo momento, el contexto de dichos objetos, con el fin de mejorar el
trabajo de los colaboradores que los comparten;
7. el administrador de contenidos vı́a NFC [Romero et al., 2013] enriquece las reuniones
co-localizadas al proveer a los colaboradores información relevante 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
que están cerca del área de despliegue de dicha información.
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 las
funcionalidades relacionadas al rol de cada colaborador en su respectiva instancia. Finalmente,
ambas aplicaciones usan la barra de colaboradores para proveer conciencia de grupo.
Después de haber descrito brevemente las aplicaciones identificadas durante la fase de análisis,
a continuación se describen los escenarios representados en la Figura 4.1:
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 entre los
colaboradores, en función de su interacción con dichos objetos. A partir de las relaciones
encontradas, se hacen sugerencias pro-activas, tales como poner a disposición de los colaboradores aplicaciones adecuadas para manipular un objeto dado, dependiendo de su
rol, o asociar diferentes conversaciones textuales en curso que hacen referencia a dicho
objeto. La herramienta relacionada con este escenario es la de desktop enriquecido.
2. El escenario “Remodelación de la interfaz de usuario” permite la modificación de componentes mediante las siguientes acciones: ocultar, sustituir o agregar; en particular, 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 la herramienta de mapas mentales los iconos relacionados con
el rol de autor son mostrados, solo para los colaboradores que tienen asignado dicho rol)
y las aplicaciones (e.g., desktop enriquecido) en función del rol de los colaboradores y del
tamaño de la pantalla del dispositivo.
3. El escenario “Redistribución de una aplicación colaborativa” adapta los componentes que
son afectados por el trabajo co-localizado y redistribuido. Algunos de los componentes
Capı́tulo 4
79
detectados que son susceptibles de dichas modificaciones corresponden a los espacios
compartidos y públicos, a la conciencia de grupo y al uso de dispositivos con pantallas
grandes y de buena resolución para una mejor interacción (e.g., un pizarrón interactivo).
Las herramientas asociadas a este escenario corresponden a: herramienta de votación,
editor de mapas mentales, editor de dibujos y barra de colaboradores.
4. El escenario “Mejoramiento de la conciencia grupal” 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 la
de medios de contacto y disponibilidad.
5. El escenario “Manejo de intromisiones” adapta la información desplegada en un dispositivo, e.g., pizarrón interactivo o una computadora portátil, al detectar a una persona que
no pertenece al equipo de trabajo. En este caso, 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.
6. El escenario “Suministro de información relevante” permite proveer información que puede
ser útil a los colaboradores, considerando el lugar, la fecha y el rol de estos. Este escenario
tiene asociada la herramienta administrador de contenidos vı́a NFC.
7. El escenario “Notificaciones multi-modales” 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.
4.3
Escenario 1: Mejoramiento del trabajo colaborativo
Este escenario describe un entorno virtual cuya finalidad es mejorar la colaboración entre los
miembros de un grupo. Para lograr este fin, dicho entorno ofrece aplicaciones colaborativas
adecuadas, dependiendo del rol de cada colaborador, y permite asociar objetos de diferentes
aplicaciones mediante referencias deı́cticas, las cuales mantienen en todo momento el contexto
de dichos objetos.
Antes de describir el escenario, se presenta una introducción acerca de las aplicaciones colaborativas adaptativas que han sido identificadas en este escenario, ası́ como de los roles y la
granularidad de los objetos compartidos soportados por estas aplicaciones.
80
4.3.1
Preámbulo
Para relacionar y mantener el contexto de los objetos producidos durante una sesión de trabajo, un grupo de colaboradores utiliza un desktop enriquecido que provee varias aplicaciones
colaborativas diseñadas para trabajar en conjunto.
Una instancia del desktop enriquecido es ejecutada automáticamente al momento de que
cada uno de los colaboradores ingresa a la sesión para trabajar en las tareas asignadas. En
este caso de estudio, el desktop enriquecido ofrece tres aplicaciones, cuyos objetivos pueden
estar relacionados entre sı́ mediante referencias deı́cticas para enriquecer la interacción. Las
aplicaciones son las siguientes:
1. 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.
2. Un editor colaborativo que permite la fragmentación de documentos HTML para facilitar
la producción concurrente. Una imagen que está siendo desplegada por este editor puede
ser arrastrada hacia el pizarrón multi-usuario donde puede ser modificada. De esta manera, no hay necesidad de realizar las tradicionales operaciones de copiar/pegar o abrir
archivo para acceder a dicha imagen desde el pizarrón multi-usuario. Además, la actualización de la imagen desplegada por el editor colaborativo se hace de manera automática,
ya que éste mantiene un identificador de dicha imagen mientras ésta permanece abierta
en el pizarrón multi-usuario.
3. Un servicio de mensajerı́a que soporta la comunicación directa entre los miembros de
un grupo y que es capaz de relacionar diferentes conversaciones que hacen referencias
deı́cticas a un mismo objeto compartido que está siendo manipulado mediante el editor
colaborativo o el pizarrón multi-usuario.
La granularidad de los objetos compartidos soportada por el editor colaborativo va desde
una palabra, una frase, un párrafo o una sección hasta todo el documento. De manera similar, el pizarrón multi-usuario permite la manipulación de 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 visualizar imágenes;
3. el rol de revisor permite a los colaboradores hacer comentarios respecto a la forma y al
contenido de documentos y diagramas.
Capı́tulo 4
81
Es importante mencionar que no todas las aplicaciones colaborativas adaptativas contenidas
en el desktop enriquecido están visibles en todo momento para evitar que el usuario se sature
con aplicaciones que no son de utilidad para la actividad en curso. Con el objetivo de proveer
a los colaboradores con un entorno colaborativo apropiado, las herramientas están disponibles
dependiendo del rol actual del colaborador. De este modo, un colaborador con el rol de escritor,
podrı́a requerir 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́ste podrı́a necesitar que la
mensajerı́a instantánea trabaje de manera coordinada con el editor colaborativo y el pizarrón
multi-usuario para hacer comentarios acerca del texto o de los diagramas del documento.
4.3.2
Descripción del escenario
Suponga que un grupo compuesto por cuatro miembros, Alice, Isaac, Jenny y Sandy, está
preparando un reporte técnico de manera distribuida. Aunque los miembros del grupo utilizan
dispositivos heterogéneos, estos tienen caracterı́sticas técnicas suficientes (e.g., buen tamaño
y alta definición de pantalla, ası́ como alto 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 revisarla. 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 la
revisen conjuntamente dicha sección, ya que ella tiene algunos problemas para expresar sus
ideas. En consecuencia, estos colaboradores deciden entablar una comunicación directa mediante la mensajerı́a instantánea, mientras que el editor colaborativo está a cargo de mostrarles
los párrafos sujetos a revisión.
El desktop enriquecido provee una funcionalidad de deixis, la cual permite a los colaboradores crear referencias deı́cticas, en forma de ligas de hipertexto, entre objetos de la herramienta de la mensajerı́a instantánea (e.g., palabras deı́cticas como this figure, the next section,
this paragraph, those references o here) y objetos del editor colaborativo (e.g., un tı́tulo, un
párrafo, una frase, una palabra, una referencia bibliográfica, una figura o una sección). Gracias
a ésta funcionalidad, los colaboradores no necesitan copiar los objetos referenciados desde el
editor colaborativo hacia la mensajerı́a instantánea cuando están revisando. De este modo,
los objetos referenciados siempre mantienen su contexto en el editor colaborativo, i.e., párrafos
anteriores y siguientes, figuras asociadas y referencias bibliográficas.
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 mensajerı́a instantánea para referirse a un párrafo mostrado en
el editor colaborativo
Mediante la funcionalidad deixis, Isaac escribe en la mensajerı́a instantánea: “. . . in
this paragraph, you are using the concept “view-controller pair” without defining it . . . ”. Como
puede observarse en la Figura 4.2, las palabras deı́cticas “this paragraph” de la frase previa
tienen una liga de hipertexto que apunta a un párrafo del documento abierto en el editor colaborativo. Cuando Sandy da clic en la liga creada por Isaac, el editor colaborativo muestra el
párrafo correspondiente a la mitad de la vista y lo resalta con letra de color roja, en este caso.
Como el párrafo en cuestión mantiene su contexto, i.e., referencias bibliográficas, párrafos
circundantes y figuras referenciadas, Sandy puede darse cuenta que el comentario de Isaac es
correcto, ya que ella pueda fácilmente verificar que el concepto “view-controller pair” no está
definido en párrafos previos de la sección.
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. Como se ilustra en la Figura 4.3, la mensajerı́a instantánea muestra que Alice escribió
Capı́tulo 4
83
“. . . I’d like to highlight H1 in this diagram”. Al igual que Isaac, Alice creó una referencia
deı́ctica a la figura 1 del reporte técnico. De este modo, cuando Jenny da clic en las palabras
deı́cticas “in this diagram”, el editor colaborativo muestra el diagrama correspondiente a la mitad de la vista resaltándolo mediante un borde color azul. Este diagrama referenciado también
mantiene su contexto, i.e., sección contenedora, tı́tulo de la figura y párrafos circundantes.
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 mensajerı́a instantánea para referirse a una figura mostrada en
el editor colaborativo
Como no es posible modificar este diagrama desde el editor colaborativo, el desktop enriquecido provee una funcionalidad que permite a los colaboradores hacer una réplica de tal diagrama
en el pizarrón multi-usuario, donde este puede ser modificado. Esta réplica mantiene una referencia contextual al diagrama mostrado en el editor colaborativo (en este caso, un identificador
de objeto interno y la localización del objeto en el documento). Por lo tanto, gracias a esta
referencia contextual, el desktop enriquecido permite a los colaboradores reemplazar la versión
caducada del diagrama mostrado en el editor colaborativo, por la nueva versión creada en el
pizarrón multi-usuario.
84
Como Alice y Jenny decidieron modificar tal diagrama, una réplica es automáticamente
creada en el pizarrón multi-usuario. En ese momento, el desktop enriquecido deduce que Sandy
e Isaac están escribiendo un párrafo que hace referencia a la figura que está siendo modificada
por Alice y Jenny. En consecuencia, el desktop enriquecido 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 también es hecha a Alice
y Jenny. En caso de que Sandy e Isaac estén interesados en seguir la conversación de Alice y
Jenny (cf. Figura 4.4) y viceversa (cf. Figura 4.5), ellos pueden acceder a estas conversaciones
por medio de una nueva pestaña agregada en sus respectivos mensajeros instantáneos.
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
El desktop enriquecido pretende hacer más eficiente el trabajo grupal, adaptándose a las
actividades de los colaboradores. Gracias a estas funcionalidades adaptativas, 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 los objetos creados conjuntamente.
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
Adaptación al contexto de uso de los sistemas colaborativos
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 el desktop enriquecido considera el
rol del colaborador para ofrecer solo las aplicaciones relevantes para ese rol. La segunda forma
de adaptación considera al entorno compartido ya que, por un lado, el desktop enriquecido
permite relacionar objetos de diferentes aplicaciones mediante referencias deı́cticas. Por otro
lado, la mensajerı́a instantánea es capaz de detectar diferentes conversaciones en curso que
hacen referencia a un mismo objeto compartido, con el fin de hacer sugerencias pro-activas a
los colaboradores, e.g., seguir la conversación de sus colegas para conocer sus intenciones de
cambios respecto a un objeto compartido dado.
86
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 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 o a objetos relacionados.
Requerimientos funcionales y no funcionales
Los requerimientos funcionales del desktop enriquecido se listan a continuación:
• Autentificar a cada colaborador al ingresar a una sesión.
• Adaptar la interfaz de usuario dependiendo cada colaborador, i.e., mostrar los ı́conos de
acceso rápido a las aplicaciones relacionadas con el rol asignado.
• Permitir que los colaboradores puedan usar la función Deixis a partir de la mensajerı́a
instantánea para crear referencias deı́cticas que referencien diferentes objetos compartidos, los cuales pueden ser párrafos, palabras o imágenes, que sean desplegados por el
editor colaborativo. La creación de referencias deı́cticas requieren los siguientes pasos:
1) seleccionar el ı́cono de 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 y 4) aceptar para terminar de crear la nueva deixis.
• Permitir el acceso a la referencia deı́ctica al seleccionar con el cursor la palabra deı́ctica.
En consecuencia, el desktop enriquecido podrá mostrar 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 referencie
a una imagen, esta estará enmarcada con un recuadro de color azul.
• Crear una réplica de la imagen referenciada del editor colaborativo en el pizarrón multiusuario para hacer modificaciones sobre dicha imagen. Una vez terminadas las modificaciones, el objeto será actualizado automáticamente en el documento, donde ha sido
referenciado.
• Sugerir seguir una conversación al detectar que dos conversaciones hacen referencia a un
objeto compartido o a objetos relacionados.
Los requerimientos no funcionales del desktop enriquecido corresponden a:
Capı́tulo 4
87
1. Mostrar en medio de la vista del editor colaborativo el objeto compartido al que se está
haciendo referencia.
2. Permitir la creación de varias referencias deı́cticas en una conversación, ası́ como mantener
las ligas a dichos objetos en forma de hipertexto.
3. Mostrar las palabras deı́cticas, e.g., in this paragraph, en la mensajerı́a instantánea en
color azul y subrayada.
4. Abrir el pizarrón multi-usuario cuando los colaboradores deseen crear una réplica de una
imagen referenciada, la cual posteriormente será modificada y actualizada.
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 públicas de sus colegas que están relacionadas con
el trabajo en desarrollo (cf. Figura 4.4 y 4.5).
Las variables que son consideradas para la adaptación contextual corresponden a: 1) rol del
colaborador, 2) 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 juega 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́ también acceso a la mensajerı́a instantánea.
La variable de referencia deı́ctica contiene las figuras o el texto al que se hace referencia sin
que estos pierdan su contexto.
La variable de objetos compartidos en uso almacena los objetos en uso de todos los colaboradores que interactúan en un momento dado. Dicha variable permite identificar el grado de
relación entre dichos objetos compartidos para proveer sugerencias pro-activas.
La variable de conversaciones actuales registrará las conversaciones de los colaboradores en
un momento dado. Esta variable permitirá que dichas conversaciones sean visualizadas por
otros colaboradores como resultado de una 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. Después de que el desktop
enriquecido autentifica al colaborador solicita a una base de datos los roles de dicho
88
usuario, para determinar las aplicaciones relacionadas con los roles obtenidos, con la
finalidad de ponerlas accesibles al colaborador, e.g., un revisor requiere 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 una 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 convierte la palabra seleccionada en una hiperliga con estilo bold y 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 circundada 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 texto.
4. El colaborador selecciona la opción ”Make a copy”. Esta opción es activada después
de que una figura fue seleccionada desde el editor colaborativo. 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 un colaborador que solicitó dicha copia, desde el
editor colaborativo. Al momento de solicitar dicha actualización, el pizarrón multi-usuario
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 un objeto compartido o bien a objetos relacionados. En consecuencia, mediante una ventana, el
desktop enriquecido, propone a los colaboradores en cuestión seguir la conversación actual
que llevan a cabo sus colegas por mensajerı́a instantánea para facilitar su trabajo, ya que
todos estos colaboradores hacen referencia al mismo objeto o a objetos relacionados.
Capı́tulo 4
89
7. Los colaboradores aceptan 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 otros colaboradores (cf. Figura 4.2).
4.4
Escenario 2: Remodelación de la interfaz de usuario
El objetivo de esta propuesta es ocultar, sustituir o agregar componentes de los sistemas colaborativos. 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 algunos de estos componentes por muchas razones. Algunos
motivos para ocultar o sustituir los componentes o funcionalidades se mencionan a continuación:
• mostrar solo los iconos relacionados con la actividad en curso, e.g., si un revisor de un
artı́culo ingresa al editor colaborativo, esta aplicación debe ocultar los ı́conos no relacionados a sus actividades, e.g., el ı́cono de insertar imagen;
• ocultar componentes cuando:
– se detecte que algunos de los ı́conos relacionados con el rol no sean utilizados por el
colaborador que esté usando la instancia de una aplicación;
– estos no tengan funcionalidad debido a que el recurso humano o fı́sico asociado no
está disponible, e.g., el ı́cono de una impresora debe ocultarse cuando está descompuesta o el avatar de un colaborador fuera de lı́nea puede ser agregado a una lista
de colaboradores ausentes;
• 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 ejemplifica el presente escenario es un editor de mapas mentales que
permite que los colaboradores puedan asumir los siguientes roles:
• administrador, el cual permite crear un nuevo mapa mental, elegir a los participantes y
asignarles un rol;
• autor, el cual da la posibilidad de agregar, modificar, mover o eliminar elementos en el
mapa mental, y
• revisor, el cual permite agregar, modificar o eliminar comentarios sobre los elementos
del mapa mental.
Además dicha herramienta soporta las siguientes configuraciones 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 del dispositivo en uso. 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
Supongamos que un grupo de colaboradores, compuesto por Coello, Mejia, Fraga,
Chakraboborty y Morales, necesita realizar un mapa mental sobre software libre. Dichos colaboradores planearon formalmente una cita que fue registrada en la agenda de la sala de
reuniones.
Coello y Fraga asisten a la reunión llevando consigo cada uno un teléfono inteligente, mientras
que Morales acude con su tablet PC. Cuando Coello, Fraga y Morales 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, Mejia y Chakraborty entran al sistema manualmente
introduciendo su nombre de usuario y contraseña mediante su tablet PC, ya que ellos han
decidido interactuar con sus colegas de manera remota.
Cuando Coello 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 (cf. Figura 4.6). Además, se visualiza una barra de colaboradores donde se muestran los colaboradores virtualmente presentes,
en este caso el nombre y la foto de Mejia y Chakraborty. Desde la pantalla principal, Coello
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. Coello decide
Capı́tulo 4
91
dar el rol de revisor a Mejia y Chakraborty, en tanto el rol de autor es asignado a Coello,
Fraga y Morales (cf. Figura 4.7). En particular, el rol de autor permite la adición, 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 comentarios asociados a dichos elementos. Una vez que
Coello 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.
Figura 4.6: Pantalla principal donde se muestran las aplicaciones disponibles y una barra de
colaboradores que exhibe a los miembros ausentes y virtualmente presentes
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, la interfaz de usuario desplegada en el pizarrón interactivo muestra a
detalle el mapa metal ası́ como las funcionalidades relacionadas con el rol de revisor y autor
(cf. Figuras 4.8 y 4.9 respectivamente).
Por otro lado, la interfaz de usuario de Morales muestra una vista detallada del mapa mental
(cf. Figura 4.10a). En tanto que la interfaz de usuario que puede visualizar Mejia 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 (cf. Figura 4.10b). Por el contrario,
92
Figura 4.7: Pantalla para elegir a los participantes en la creación del mapa mental y sus roles
en el dispositivos de Fraga, la interfaz de usuario de esta herramienta muestra una vista radar
interactiva [Utwin et al., 1996] donde se presenta únicamente la estructura del mapa mental
(cf. Figura 4.10c).
A través de la vista radar interactiva mostrada en el dispositivo móvil de Fraga puede añadir,
modificar, mover y eliminar elementos, mientras observan una vista detallada del mapa mental
en el pizarrón interactivo. Mejia 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 autorizadas al rol del colaborador.
Después de que Fraga trabaja un largo rato en el mapa mental, él decide guardar su trabajo
en su teléfono inteligente. Entonces Fraga selecciona el ı́cono de guardar, el cual despliega un
letrero indicando que su dispositivo no tiene suficiente espacio para almacenar el diagrama, ası́
que el editor de mapas mentales propone utilizar el disco duro de la tablet PC de Morales 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 colaborativos 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 partir del rol del colaborador, el
editor de mapas mentales decide ocultar los iconos no utilizados. En el caso de Mejia, el editor
de mapas mentales solo ofrece las funcionalidades que le permiten manipular (agregar, modificar
Capı́tulo 4
93
Figura 4.8: Vista del mapa mental cuando un colaborador asume el rol de revisor
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 de las dimensiones de la pantalla del dispositivo en uso, y 2) la funcionalidad “guardar localmente” es sustituida por guardar en otro dispositivo, e.g., un servidor
o el dispositivo que está usando Morales.
4.4.3
Editor de mapas mentales
El editor de mapas mentales ofrece principalmente tres caracterı́sticas: 1) permite que el grupo
de colaboradores trabaje de manera co-localizada y distribuida, 2) adapta las funcionalidades
ofrecidas dependiendo del rol del colaborador y 3) adapta la vista del mapa mental al tamaño
y a la resolución de la pantalla del dispositivo en uso.
Los requerimientos funcionales del editor de mapas mentales se presentan a continuación:
1. Identificar al administrador del mapa mental.
94
Figura 4.9: Vista del mapa mental cuando un colaborador asume el rol de autor
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 y eliminar elementos o comentarios desde una vista detallada
mostrada en un pizarrón interactivo o una tableta.
5. Permitir agregar, modificar y 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.
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).
Capı́tulo 4
95
(a) Vista detallada en la tablet de un autor
co-localizado
(b) Vista detallada en la tablet de un
revisor distribuido
(c) Vista radar interactiva en
el teléfono de un autor colocalizado
Figura 4.10: Adaptabilidad de la interfaz de usuario del editor colaborativo de mapas mentales
con base en la configuración del grupo, las dimensiones de la pantalla y el rol del usuario
96
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.
5. Permitir exportar el mapa mental a una imagen en formato PNG.
Interfaz de usuario
Para llevar a cabo la adaptación al contexto, la aplicación editor de mapas mentales considera
las siguientes variables contextuales: 1) el rol del colaborador, 2) la configuración del grupo y
3) las dimensiones de la pantalla de despliegue.
Los roles que puede asumir un usuario son: 1) administrador, 2) autor y 3) revisor. En
el caso del administrador , la interfaz de usuario solo muestra las opciones necesarias para
asignar los roles y establecer el nombre del mapa mental (cf. Figura 4.7). En el caso del autor,
la interfaz de usuario muestra las funcionalidades necesarias para agregar, modificar, mover o
eliminar elementos (cf. Figura 4.9). Finalmente, la interfaz de usuario de un revisor ofrece
las mismas funcionalidades que para un autor, con la diferencia de que el autor manipula
elementos y el revisor manipula comentarios (cf. Figura 4.8).
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 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 (cf. Figura 4.10).
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 crea un nuevo mapa mental: la aplicación 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 selecciona la notificación de participación en la creación de
un 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). En las Figuras
Capı́tulo 4
97
4.9 y 4.8 se muestra la interfaz de usuario del editor colaborativo de mapas mentales
desplegada en el pizarrón interactivo, cuando dos usuarios juegan los roles de revisor y
autor.
De igual manera, la interfaz de usuario se adapta de acuerdo a la combinación de las siguientes variables contextuales: a) configuración del grupo y b) dimensiones de la pantalla
de despliegue. Tanto para los colaboradores co-localizados como para los distribuidos que
utilizan 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 cada conexión entre un
par de nodos, si existen (cf. Figura 4.10a). Para los participantes distribuidos, se muestra adicionalmente una barra de los colaboradores fı́sicamente presentes en el lugar de
reunión, virtualmente presentes y ausentes (cf. Figura 4.10b).
En la vista radar interactiva únicamente se puede observar la estructura del mapa mental,
ya que las dimensiones de la pantalla del dispositivo no permiten una buena visibilidad
de los detalles del mismo (cf. Figura 4.10c).
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 un colaborador, ya sea autor o revisor, se ven reflejados en el pizarrón
interactivo y en los dispositivos de todos sus colegas.
4. El mapa mental sobrepasa las dimensiones del pizarrón interactivo: la vista
del mapa mental presentada en dicho pizarrón muestra una barra de desplazamiento
horizontal y una vertical.
4.5
Escenario 3: Redistribución de una aplicación colaborativa
Este escenario pretende ilustrar funcionalidades necesarias cuando los colaboradores están trabajando co-localizadamente (cara a cara) o distribuidamente. Una caracterı́stica importante
es redistribuir la IU en los dispositivos de los colaboradores colocalizados; mientras que se
centraliza la IU de los colaboradores reditribuidos, ası́ como proveerlos de la conciencia de
grupo.
4.5.1
Preámbulo
Los colaboradores no siempre trabajan de manera meramente co-localizada o distribuida, en
algunas ocasiones trabajan de manera hı́brida, i.e., algunos de manera co-localizada y otros
98
de manera distribuida en una misma sesión colaborativa. Algunos de los componentes que
se muestran en la sesión actual de cada colaborador son susceptibles a ser modificados, por
ejemplo:
• 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 subgrupo 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 de manera co-localizada y distribuida;
• el espacio de trabajo compartido en una sesión co-localizada podrı́a ser desplegado en un
dispositivo con una pantalla 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 el dispositivo personal de cada integrante;
• en una sesión co-localizada, las funcionalidades de un sistema colaborativo son mostradas
dependiendo los roles de los colaboradores.
Para ejemplificar este escenario se usará la herramienta de votación, la cual intenta facilitar
y agilizar el proceso de una sesión de votación, permitiendo a los votantes sufragar de manera
electrónica, mediante sus dispositivos móviles, sin importar si se encuentran juntos en el lugar
de reunión (co-localizados) o en un cualquier otro lugar (distribuidos). En dicha aplicación
se utiliza el término “presente” para referirse a los colaboradores co-localizados y el termino
“virtualmente presente” para referirse a los colaboradores distribuidos
Los roles que puede asumir un usuario en la herramienta de votación son: 1) proponente, el
cual le permite plantear una pregunta hacia un grupo de colaboradores y establecer las reglas
de la sesión de votación en curso y 2) votante, el cual le autoriza la emisión de su voto durante
dicha sesión.
4.5.2
Supongamos que Coello, el jefe del Departamento de Computación de una universidad, organizó una reunión en una sala de juntas que cuenta con un pizarrón interactivo. El objetivo de
la reunión es elegir al nuevo coordinador académico. Al llegar a la sala de juntas, cada participante es autenticado en el sistema ya sea: 1) de manera automática a través de NFC (Near
Field Communication) o 2) por medio de una ventana que le solicita su nombre de usuario y
contraseña. Al inicio de la reunión, sólo algunos de los participantes están fı́sicamente presentes.
La información de consciencia sobre la presencia de los miembros no sólo puede ser inferida
de manera natural, sino que también es mostrada en el pizarrón interactivo por medio de una
barra que presenta a los miembros ausentes y virtualmente presentes.
Capı́tulo 4
99
Después de unos minutos, dos de los miembros ausentes ingresan al sistema a través de
Internet desde el lugar donde se encuentran. En consecuencia, la barra de colaboradores se
actualiza automáticamente, quitando su foto y nombre de la sección de miembros ausentes y
colocándolos en la sección de miembros virtualmente presentes.
Después, Coello decide que la reunión dé inicio y pasa a la zona donde se encuentran el
pizarrón interactivo para introducir la información correspondiente. Al acercarse a dicha zona,
una etiqueta NFC detecta su presencia y, en respuesta, el sistema inicia automáticamente una
nueva sesión. En el pizarrón interactivo se muestra un mensaje que informa dicho evento y una
ventana con las aplicaciones disponibles. Desde dicha ventana, Coello inicia la herramienta
de votación, la cual le asigna el rol de proponente. Por medio del pizarrón interactivo, Coello
puede plantear a todos los profesores presentes la pregunta principal por la cual se organizó la
reunión, las opciones de respuesta y las reglas de la sesión de votación.
Coello escribe la pregunta en el pizarrón interactivo y establece que la votación puede ser
anónima, i.e. los votantes pueden elegir si hacen público o no su nombre de usuario al votar.
Coello además determina que la votación será válida siempre y cuando haya votado al menos
el 90% del total de los profesores del departamento (cf. Figura 4.11). Una vez que Coello ha
confirmado la información sobre la votación en el pizarrón interactivo, cada dispositivo móvil
de los miembros fı́sica y virtualmente presentes recibe una notificación de votación. Cuando un
miembro selecciona dicha notificación, la herramienta de votación se inicia automáticamente
en su dispositivo móvil y le asigna el rol de votante.
Figura 4.11: Datos de la votación en curso ingresados por el proponente en el pizarrón interactivo
100
La interfaz de usuario de dicha aplicación es capaz de adaptarse a la configuración del grupo
(distribuido o co-localizado) y al rol de cada participante (proponente o votante).
Para los miembros presentes en la sala, dicha adaptación consiste en mostrar en su dispositivo
móvil únicamente las posibles opciones de respuesta para la pregunta actual (cf. Figura 4.12b),
ya que la descripción de la misma es mostrada en el pizarrón interactivo (cf. Figura 4.12a).
En el caso de los miembros virtualmente presentes, la adaptación consiste en mostrar en su
dispositivo móvil la pregunta, las opciones de respuesta y tres listas de consciencia de grupo: 1)
miembros ausentes, 2) miembros virtualmente presentes y 3) miembros fı́sicamente presentes en
la sala (cf. Figura 4.12c). En ambos casos, la aplicación proporciona una opción de abstención
y un botón para emitir un voto anónimo, debido a que Coello ası́ lo estableció.
La aplicación da un tiempo de espera para que los profesores analicen las opciones disponibles
y emitan su voto. Al finalizar dicho tiempo, la aplicación detecta que el porcentaje mı́nimo
para validar la votación no ha sido alcanzado, ası́ que decide mostrar en el pizarrón interactivo un mensaje de aviso que proporciona las siguientes opciones: 1) validar la votación con
el porcentaje actual, 2) posponer la votación (con el fin de alcanzar el porcentaje requerido
en otro momento) y 3) cancelar la votación. Coello selecciona la primera opción. Como resultado, la aplicación muestra los resultados en el pizarrón interactivo para que los presentes
puedan visualizarlos (cf. Figura 4.13) y los envı́a a los dispositivos móviles de los colaboradores
virtualmente presentes (cf. Figura 4.14).
Tanto en el pizarrón interactivo, como en los dispositivos móviles de los miembros virtualmente presentes, los profesores pueden visualizar el porcentaje de votación de cada opción, ası́
como los nombres de quienes votaron por cada una de ellas. En el caso de los que votaron como
incógnito, la palabra “anónimo” es mostrada en lugar del nombre de usuario. De esta manera,
termina la sesión de votación.
Adaptación del contexto de uso de los sistemas colaborativos
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 lleva a cabo cuando la herramienta de votación
distingue entre un rol de proponente y un rol de votante puesto que la interfaz de usuario es
diferente para cada uno.
La adaptación al conjunto de plataformas ocurre cuando el sistema sugiere a Coello usar
el pizarrón interactivo, ya que detecta que él está cerca del dispositivo mencionado. Otra forma
de adaptación a la plataforma consiste cuando la herramienta adapta su interfaz de usuario a
los dispositivos móviles que están usando los votantes.
La adaptación al entorno común se logra cuando la herramienta muestra quiénes trabajan
de manera co-localizada (presentes) y de manera distribuida (virtualmente presentes) en la
barra de colaboradores.
Capı́tulo 4
101
(a) Pregunta sujeta a votación y opciones detalladas de respuesta
mostradas a los participantes co-localizados en el pizarrón interactivo
(b) Opciones simplificadas de respuesta en el dispositivo móvil de
un votante co-localizado
(c) Opciones detalladas de respuesta en el dispositivo móvil de
un votante distribuido
Figura 4.12: Adaptabilidad de la interfaz de usuario de la herramienta de votación con base en
la configuración del grupo y el rol del usuario
102
Figura 4.13: Resultados de la votación mostrados a los participantes co-localizados en el
pizarrón interactivo
Figura 4.14: Resultados de la votación mostrados en los dispositivos de los participantes distribuidos
Capı́tulo 4
4.5.3
103
Herramienta de votación
Como se mencionó, esta herramienta permite crear votaciones electrónicas aún cuando la ubicación de los colaboradores sea distinta, i.e., co-localizada o distribuida, o los dispositivos en uso
sean heterogéneos, e.g., pizarrón interactivo y dispositivo móvil. Además, dicha herramienta
ofrece las funcionalidades necesarias dependiendo de dos variables: 1) el rol (votante o proponente) de cada participante y 2) el tiempo establecido para generar el voto.
A continuación se presentan los requerimientos de la herramienta de votación, con el fin de
expresar las caracterı́sticas y restricciones de la misma.
Los requerimientos funcionales de la herramienta de votación son los siguientes:
• Identificar y asignar un rol a cada usuario con base en el tipo de dispositivo desde el cual
accede a la aplicación.
• Adaptar su interfaz de usuario de acuerdo al rol y a la ubicación fı́sica del usuario (i.e.,
si está presente o no en la sala de reunión).
• Permitir que el proponente organice una nueva votación. En particular, se le debe permitir
plantear una pregunta hacia un 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.
• Mostrar en los dispositivos móviles de los miembros virtual y fı́sicamente presentes, las
posibles opciones de respuesta a la pregunta de votación, una opción de abstención y, si
la votación lo permite, una opción de voto anónimo.
• Mostrar en los dispositivos móviles de los miembros virtualmente presentes la pregunta
que fue sometida a votación e información detallada sobre cada opción de respuesta.
• Garantizar, siempre que sea posible, la igualdad entre las opciones de respuesta, sin
favorecer a ninguna.
• 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.
• Brindar al proponente la posibilidad de iniciar la votación, lo cual hará posible que se
pueda recibir y registrar los votos de los electores.
104
• Mostrar un tiempo de espera en el pizarrón interactivo para que los miembros fı́sica y
virtualmente presentes emitan su voto.
• Solicitar al votante la confirmación de su voto.
• Contabilizar los votos de los usuarios y calcular el porcentaje de votación.
• Si no se alcanzó el porcentaje mı́nimo de votación, la aplicación debe mostrar opciones
para: 1) validar la votación con el porcentaje actual, 2) posponerla o 3) cancelarla.
• Si se alcanzó el porcentaje mı́nimo o se validó la votación manualmente, la aplicación debe
mostrar los resultados en el pizarrón interactivo y enviarlos a los dispositivos móviles de
los miembros virtualmente presentes.
• Recuperar una sesión de votación establecida como pospuesta.
• Eliminar toda la información de una sesión de votación establecida como cancelada.
Los requerimientos no funcionales de la herramienta de votación son en listados a continuación:
• Almacenar los votos de tal manera que se garantice la privacidad de los mismos. No se
puede tener acceso a los votos almacenados, hasta que se produzca el cierre de la votación.
• Transmitir la información de forma que se garantice la integridad y autenticidad de la
misma.
Interfaz de usuario
La adaptación de la aplicación al contexto de uso considera las siguientes variables contextuales: 1) detección de un colaborador, 2) aplicación en ejecución, 3) rol del colaborador y 4)
configuración del grupo.
La variable “detección de un colaborador” almacena el nombre del colaborador que está
cerca al pizarrón interactivo que ofrece las aplicaciones disponibles. En el caso de que dicho
colaborador ejecute la herramienta de votación (variable “aplicación en ejecición”) desde el
pizarrón, la herramienta de votación le asigna el rol de proponente. Por consiguiente, el resto
de los colaboradores tendrán el rol de votante.
La variable “rol de colaborador” sirve para desplegar la interfaz de usuario relacionada al
rol. En el caso del rol de proponente, la interfaz de usuario contiene varios campos a llenar,
e.g., tema, tiempo lı́mite para la votación y porcentaje mı́nimo (cf. Figura 4.11). En el caso
del rol de votante, se puede mostrar dos tipos de interfaces de usuario dependiendo de la
variable “configuración de grupo” que puede tener una de las siguientes opciones: co-localizado
o distribuido.
Capı́tulo 4
105
La interfaz de usuario de los votantes co-localizados tendrá como opciones los nombres de
los candidatos (cf. Figura 4.12b). Otra interfaz de usuario que visualizan estos votantes es la
de resultados, la cual es desplegada en el pizarrón interactivo (cf. Figura 4.13).
Mientras que los votantes distribuidos tendrán dos interfaces de usuario, las cuales son las
siguientes: 1) interfaz de usuario de votación, la cual tiene los nombres de los candidatos, una
barra de colaboradores que muestra la conciencia de grupo (presente, virtualmente presente y
ausente) y una breve descripción de cada candidato (cf. Figura 4.12c) y 2) interfaz de usuario
de resultados, la cual muestra de manera resumida el porcentaje que obtuvo cada candidato y
de ser posible indica quién voto por dicho candidato (cf. Figura 4.14).
Es importante notar que las interfaces de usuario de los votantes distribuidos tienen más
información debido a que requieren tener la información completa respecto a la votación y
conciencia de grupo.
Por otro lado, para mostrar la manera en que la herramienta de votación puede adaptarse a
cambios contextuales, se describe una lista de eventos que provocan la adaptación de dicha
aplicación:
1. Un proponente inicia una nueva sesión de votación: después de que el proponente
selecciona la herramienta de votación desde el pizarrón interactivo (cf. Figura 4.6), se
muestra una ventana donde puede ingresar la información referente a la votación (cf.
Figura 4.11). Una vez confirmada dicha información, los usuarios reciben en sus dispositivos una notificación de votación. En el pizarrón interactivo (cf. Figura 4.12a), los
usuarios co-localizados pueden observar la pregunta, las opciones de respuesta, el tiempo
de espera y las reglas de la votación, i.e., debe participar al menos el 90 % del total de
usuarios registrados y los votantes pueden sufragar de manera anónima, pero no pueden
abstenerse de votar.
2. Un votante fı́sicamente presente participa en la sesión de votación en curso:
cuando un participante fı́sicamente presente selecciona la notificación de votación, se
ejecuta la herramienta de votación en su dispositivo. La interfaz de usuario de esta herramienta se adapta a fin de desplegar únicamente las posibles opciones de respuesta para
la pregunta actual, y, si es el caso, una opción para votar como anónimo y un botón
de abstención (cf. Figura 4.12b). En el pizarrón interactivo, los votantes pueden observar información de consciencia de grupo, i.e., los colaboradores ausentes y virtualmente
presentes en la reunión (cf. Figura 4.6).
3. Un votante virtualmente presente participa en la sesión de votación en curso:
cuando un participante virtualmente presente selecciona la notificación de votación, se
ejecuta la herramienta de votación en su dispositivo. La interfaz de usuario de la herramienta se adapta de manera que muestra tres listas de consciencia de grupo: 1) ausentes,
106
2) virtualmente presentes y 3) fı́sicamente presentes en la reunión; además, muestra la
pregunta, sus opciones de respuesta e 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 (cf. Figura 4.12c).
4. El tiempo de espera para emitir los votos termina: si la aplicación detecta que se
alcanzó el porcentaje mı́nimo de participación, la votación es establecida como validada.
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) posponerla o 3)
cancelarla.
4.6
Escenario 4: Mejoramiento de la conciencia grupal
Esta propuesta modifica el medio de contacto y la disponibilidad de dos colaboradores dependiendo de sus actividades, preferencias y dispositivos en uso.
4.6.1
Preámbulo
Los sistemas colaborativos permiten diferentes medios de contacto, e.g., el sistema de mensajerı́a
instantánea permite la comunicación mediante texto, audio o video en tiempo real. Dichos
sistemas, e.g, la mensajerı́a instantánea, no cambian de manera automática los medios de
comunicación, i.e., no consideran la actividad, el dispositivo o la aplicación en uso, lo cual obliga
a los colaboradores tener que usar diferentes sistemas para llevar a cabo la comunicación.
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 que permita a los
colaboradores establecer manualmente dicha disponibilidad o el medio de contacto.
4.6.2
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
también es responsable de escribir la sección de introducción. Finalmente, Alice y Sandy están
encargadas respectivamente de escribir y revisar la sección de conclusiones, pero Alice tiene
asignado la revisión de la sección de introducción y de desarrollo.
Capı́tulo 4
107
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. Con base en las
preferencias de Isaac, el espacio de trabajo determina su disponibilidad como sigue:
1. Ocupado para los colegas: a) cuya actividad actual es muy poco similar o no similar a la
suya, aún si una de sus actividades potenciales es más o menos similar o poco similar a
su actividad actual, y b) cuya actividad actual o potencial es 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 actividades potenciales 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 con base en sus sub-estados de disponibilidad (primer parámetro de entrada):
1. Cuando está ocupado, Isaac 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 contactable 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 está accesible, Isaac 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 de trabajo, ellas prefieren que este infiera su
disponibilidad y sus medios de contacto. Tanto Alice como Sandy deciden trabajar en la
sección de conclusiones, ası́ que ellas colocan su cursor en dicha sección para empezar a escribir
y redactar respectivamente. Dado que la fecha lı́mite de dicha actividad es relativamente
distante, el espacio de trabajo determina los siguientes sub-estado de su disponibilidad:
1. Ocupadas para colegas, cuyas actividades actuales y potenciales sean poco o no similares
a sus actuales actividades.
2. Contactable si es posible para colegas, cuya actual actividad es muy poco similar o no
similar a la suya, pero una de sus actividades potenciales es muy similar, similar, más o
menos similar o poco similar a su actividad actual.
3. Accesibles para colegas, cuya actual actividad es muy similar, similar, más o menos similar,
o poco similar a la suya.
108
Además, el espacio de trabajo establece el medio de contacto de Sandy con base en la similitud
entre sus actividades y las 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 es muy similar o similar a su actividada actual o potencial. 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 en función de 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.
Suponga que Sandy revisa la sección de conclusiones durante un rato y después detiene
su actividad para contactar a Isaac. Ella coloca su cursor en la foto de Isaac (localizado en
la barra de colaboradores) y como resultado, un ı́cono desplegable aparece para mostrar la
disponibilidad de Isaac y los medios de contacto para comunicarse con él (cf. Figura 4.15a).
Sandy nota que la disponibilidad de Isaac es contactable si es posible, ya que la fecha lı́mite de
su actividad es cercana y aún cuando sus actividades en curso no son similares, ella también es
responsable de escribir la sección de desarrollo. Por consiguiente, el medio 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. Cuando Sandy pone su
cursor sobre la foto de Alice (cf. Figura 4.15a), ella observa que la disponibilidad de su colega
es accesible ya que aunque sus actividades actuales 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 (cf. Figura 4.15a).
Isaac percibe que la disponibilidad de Sandy es ocupado (cf. Figura 4.15b), ya que aunque
la fecha lı́mite de la actividad de ella es distante, sus actividades actuales no son similares y
la actividad potencial de él (i.e., 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 actividad potencial de ella (i.e, escribir la sección de
desarrollo) es muy similar a la actividad actual de Isaac. La vista de Isaac muestra que Alice
Capı́tulo 4
109
(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
Development
Instant Messenger
Writer
Development
Sandy
Reviewer
Conclusions
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.15: Disponibilidad y medios de contacto al inicio de la sesión colaborativa.
es accesible (cf. Figura 4.15b), ya que la fecha lı́mite de la actividad de ella es distante y sus
actividades actuales son más 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.
Al igual que Sandy, Alice puede ver que la disponibilidad de Isaac es contactable si es posible
(cf. Figura 4.15c), ya que la fecha lı́mite de la actividad de él es cercana y sus actividades
actuales son más 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. A diferencia
de la vista de Isaac, la vista de Alice (cf. Figura 4.15c) muestra que Sandy es accesible, ya que
aunque sus actividades actuales 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 más o menos
similares en el mejor de los casos.
Después, Sandy 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 de trabajo detecta esta acción, no solo los sub-estados de la disponibilidad de Sandy
cambian sino también los de sus colegas cono se explica a continuación. Para llegar a un acuerdo
acerca de la estructura de esta sección, Sandy pone su cursor en la foto de Isaac otra vez y
observa que su estado de disponibilidad se volvió accesible (cf. Figura 4.16a). Ella también nota
110
que tiene medios de contacto adicionales para comunicarse con él. 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.
(a) Sandy’s view
(b) Isaac’s view
(c) Alice’s view
Collaborators
Collaborators
Collaborators
Isaac
Isaac
Accessible
Writing
Development
Video-conference
Isaac
Development
Instant Messenger
Writer
Development
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.16: Disponibilidad y medios de contacto de Sandy, Isaac y Alice una vez que Sandy
ha cambiado su actividad.
De esta manera, los medios de contacto disponibles para que Sandy establezca comunicación
con Isaac son voz y mensajerı́a instantánea, ya que aún 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 (cf. Figura 4.16a), Alice
permanece accesible, ya que la fecha lı́mite de la actividad de Alice es distante y sus actividades
actuales son más 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 ya que como se mencionó previamente, el dispositivo de
Sandy no tiene cámara.
En la vista de Isaac (cf. Figura 4.16b), Sandy se volvió accesible, ya que sus actividades
actuales son muy 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 los mismos. Por otro lado, en la vista de Alice (cf. Figura 4.16c), los medios de
contacto y la disponibilidad de Isaac permanecen sin cambios, pero Sandy se volvió contactable
Capı́tulo 4
111
si es posible ya que las actividades actuales de Alice y Sandy son más o menos similares y la
fecha lı́mite de la actividad de Sandy es cercana. Es importante mencionar que los medios
de contacto de Sandy no cambiaron, porque sus actividades actuales y potenciales son más o
menos similares en el mejor de los casos.
Adaptación del contexto de uso de los sistemas colaborativos
Este escenario aborda dos dimensiones del contexto de uso de los sistemas colaborativos. 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 consideran los dispositivos
necesarios para proveer el servicio de medios de contacto. En el caso de Isaac, él si contaba
con una cámara Web para realizar una video-conferencia, pero Sandy no tenı́a cámara, 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 el que desea hacer el contacto
(colaborador observador). Tanto la disponibilidad como el medio de contacto pueden ser calculados 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
enlistan a continuación:
1. Autenticar a los colaboradores.
2. Permitir que los colaboradores establezcan manualmente su disponibilidad desde la ventana de configuración de disponibilidad.
3. Calcular la disponibilidad de manera automática mediante el mecanismo de similitud de
las actividades potenciales y actuales del colaborador observado y del observador.
4. Permitir que los colaboradores establezcan su medio de contacto de manera manual mediante la ventana de configuración de los medios de contacto. Los medios de contacto
112
corresponden a: video-conferencia, 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 observador.
5. Calcular los medios de contacto de manera automática.
6. Mostrar la disponibilidad y el medio de contacto del colaborador observado al momento
de que el colaborador observador coloque el cursor sobre la foto del observado.
7. Abrir el medio de contacto seleccionado por el observador cuando requiere contactar al
colaborador observado.
8. Verificar que ambos tengan el hardware como el software necesario para un medio de
contacto dado;
Los requerimientos no funcionales de la herramienta disponibilidad y medios de contacto se
muestran a continuación:
1. Verificar el hardware y software necesario para los medios de contacto en un tiempo muy
breve, escasos segundos;
2. Calcular la disponibilidad en un tiempo breve, escasos segundos;
3. Informar al colaborador la razón por la que no puede utilizar un medio de contacto
especı́fico.
Las variables contextuales involucradas en la adaptación de la disponibilidad y los medios de
contacto son las siguientes: 1) similitud de las actividades, 2) disponibilidad, 3) dispositivo en
uso y 4) preferencias del colaborador observado. Las variables anteriores son necesarias tanto
para la disponibilidad como los medios de contacto, aunque estos últimos también requieren la
disponibilidad y las preferencias del usuario. Dichas variables están planteadas a detalle en la
propuesta del escenario 4.6.
La variable “similitud de las actividades” almacena el grado de similaridad entre las actividades, el cual corresponde a muy similares, similares, más o menos similares, poco similares,
muy poco similares y no similares. Este cálculo requiere la actividad actual del colaborador
observado y del observador.
La variable “dispositivos en uso” debe contener tanto el hardware como el software del
dispositivo en uso del observador y del colaborador observado, con la finalidad de ofrecer o no
un medio de comunicación en especı́fico.
Capı́tulo 4
113
La variable contextual “disponibilidad”, solo es requerida para calcular el medio de contacto;
dicha variable acepta uno de los siguientes estados: ocupado, accesible y alcanzable si es
posible. A partir de esta variable, la de similitud y la de dispositivos en uso ofrecen los medios
de contacto disponibles entre dos colaboradores.
La variable “preferencias del colaborador observado” contiene la predilección de medios de
contacto. Dicha preferencia debe ser previamente establecida por él o por algún mecanismo del
sistema.
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 la manera en que la herramienta puede adaptarse a
cambios contextuales:
1. Un 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 que deba determinar automáticamente la
disponibilidad del colaborador.
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.15 y 4.16).
3. El colaborador observador selecciona un medio para contactar al colaborador
observado. Después de seleccionar el medio de contacto, este es ejecutado para ser usado
por ambos colaboradores.
4.7
Escenario 5: Manejo de intromisiones
Esta propuesta oculta información de manera automática ante la presencia de una persona
ajena al grupo de colaboración.
4.7.1
Preámbulo
En los últimos años, la cobertura del servicio de Internet se ha ido incrementando, lo cual 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 colaborativos. Gracias a la
114
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
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 de que una persona ajena se acerque al dispositivo
es la interrupción de la comunicación, e.g., video llamada que está llevando a cabo de manera
electrónica.
4.7.2
Supongamos que una empresa de desarrollo de software recibió un reporte de errores en un
sistema de administración que ellos implementaron. Dada la gravedad del problema, la empresa
lanzó una convocatoria a todos sus desarrolladores con la finalidad de encontrar y proponer
una solución a dichos errores de software.
Un grupo de colaboradores, compuesto por Sandy, Alice e Isaac, encontraron el problema en
dicho software. Ası́ que ellos decidieron hacer un documento explicando tanto las causas de los
errores encontrados como la solución propuesta.
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 las causas de 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 restaurante 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. 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.
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 las
causas de los errores 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 como el programador se acerca a la computadora, el sistema detecta
que una persona ajena al grupo está observando de frente la pantalla de la computadora de
Capı́tulo 4
115
Sandy. Como consecuencia, el sistema oculta tanto el reporte como la conversación que ella
está llevando 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, ni 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 colaborativos. Tal adaptación se logra cuando se detecta a 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: Suministro de información relevante
Esta propuesta provee información tomando en cuenta el contexto del colaborador considerando
los dispositivos en uso, las actividades en ejecución y la información a desplegar.
4.8.1
Preámbulo
En este caso, la adaptación de la información se refiere al despliegue de esta, 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 ésta influye en su actividad actual; pero en otras ocasiones, la información no
es tan urgente como para recibirla en el momento en que se genera, como en el caso de
las reuniones de trabajo;
• rol: determina las restricciones y alcances que tiene el colaborador en el manejo de la
información;
• actividad: concierne a el suministro de 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;
116
• conjunto de plataformas: se refiere a considerar tanto el hardware como el software necesario para soportar el despliegue de la información;
• tamaño de los archivos: es 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 las preferencias del colaborador
puede recibir información relacionada.
El siguiente escenario maneja dos herramientas, las cuales son: administración de contenidos
y consultas de pacientes. La primera herramienta facilita información que se tratará en una
reunión previamente planificada. La segunda herramienta lleva el control de los pacientes,
i.e., ya que contiene los resultados de laboratorios y estudios, ası́ como las anotaciones de los
médicos, enfermeras y especialistas.
4.8.2
Supongamos que Sandy, Alice e Isaac están registrados en el sistema de consultas de pacientes
en un hospital, cada uno de ellos tienen los siguientes roles: Isaac es médico cardiólogo, mientras
que Alice es pasante de medicina y Sandy es enfermera.
Dado que Alice es pasante de medicina, el Dr. Isaac quiere que ella deduzca el padecimiento
de cinco pacientes, ası́ que él agenda una cita con Alicia en la sala de médicos. Isaac entra a
la habitación dos hora antes de la hora acordada, con el fin de establecer algunos detalles de la
reunión. En su tablet PC, el Dr. Isaac ejecuta la herramienta de administración de contenidos,
con el fin de establecer cada asunto a discutir (visita a los pacientes de los cuartos 2, 8, 15,
18 y 19) y seleccionar los expedientes de los pacientes a visitar. Dichos expedientes son una
versión resumida que es generada por la herramienta de consulta de pacientes. Al final de
este proceso, el Dr. Isaac acerca su dispositivo móvil a la etiqueta NFC situada en la entrada
de la sala de reuniones y selecciona la opción que le permite grabar la información sobre la
reunión en dicha etiqueta. Debido a las limitaciones de almacenamiento de las etiquetas NFC,
la herramienta de administración de contenidos sube a un servidor de contenidos, a través de
Wi-Fi, los expedientes de los pacientes en los formatos disponibles (e.g., html, pdf, doc).
Alice llega una hora antes a la sala de médicos y acerca su tablet PC a la etiqueta NFC, de
tal manera que cuando la distancia entre ambos es de 3 cm o menos, se establece entre ellos
una comunicación a través de NFC. Como resultado de dicha comunicación, varias acciones
tienen lugar automáticamente: 1) la herramienta de administración de contenidos es lanzada
en ejecución, 2) la sesión del participante es iniciada, y finalmente 3) la etiqueta NFC transfiere
a su dispositivo móvil la información necesaria. Una vez finalizado este proceso, en la interfaz de
Capı́tulo 4
117
usuario del administrador de contenidos se añaden ı́conos que representan los documentos
descargados, con el fin de que sean fácilmente accesibles por el usuario. Ası́ que a la hora de la
reunión Sandy ya tiene dichos expedientes.
Con el fin de descargar documentos adaptados a las caracterı́sticas del dispositivo, la herramienta de administración de contenidos toma en cuenta el espacio de almacenamiento y los
visores de documentos disponibles en el dispositivo. De esta manera, por ejemplo, si no hay suficiente espacio de almacenamiento para guardar todo el documento, se proporciona únicamente
un resumen. Del mismo modo, si el dispositivo destino tiene sólo visores postscript, un documento en este formato es descargado desde el servidor de contenidos a través de Wi-Fi.
Posterior a la reunión, Sandy y Alice deciden consultar a los pacientes que habı́an discutido.
El recorrido empieza por las patologı́as más comunes, en este caso por el paciente del cuarto 18.
Al ingresar al cuarto, la herramienta de consulta de pacientes detecta la presencia de ambas en
dicho cuarto; en consecuencia el sistema propone al Dr. Isaac delegar algunas responsabilidades
a Alice, pero él declina la sugerencia ya que él piensa que ella necesita practicar más.
Otra acción por parte la herramienta de consulta de pacientes es desplegar en ambas tablets el
expediente completo del enfermo del cuarto 18. Para el Dr. Isaac es normal tener el expediente
del paciente que visita; en cambio, Alice se sorprende porque ella tenı́a previamente a la vista el
expediente resumido del paciente del cuarto dos, puesto que ella pensó el recorrido en un orden
ascendente. Tanto Alice como el Dr. Isaac pueden ver los resultados de los estudios clı́nicos.
Terminando la visita, el Dr. Isaac agrega anotaciones y modifica la dosis de medicamento,
gracias a la mejora del paciente, en el expediente del enfermo. Alice puede ver a través de su
tablet la serie de pasos que el Dr. Isaac hace al momento de modificar el expediente.
Al momento que la dosis es modificada, la herramienta de consulta de pacientes actualiza la
información en la base de datos, posterior a la actualización de la base de datos se informa de
dicha actualización al demás personal que atiende al paciente de la cama 18, e.g., la nueva dosis
de medicamento se notifica a 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 que ésta 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
como el Dr. Isaac manipula la herramienta de consulta de pacientes. Cuando ambos llegan al
cuarto 15, el Dr. Isaac permite que Alice haga anotaciones relacionadas con el paciente usando
la herramienta mencionada. Por tal motivo, ambos tienen derechos de modificar el expediente
de dicho paciente.
Finalmente, tanto Alice como el Dr. Isaac acuden al cuarto 2 en donde Sandy está tomando
los signos vitales del paciente. Cuando ellos ingresas al cuarto, la información de los signos
vitales es actualizada inmediatamente en las tablets 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 ubicada sobre la pared con
la finalidad de que ambos vean la misma información al mismo tiempo. Ambas opciones
118
solo son desplegadas al Dr. Isaac desde su tablet ya que él tiene mayor jerarquı́a que Alice.
Isaac accede a las dos opciones, por tal motivo Alice puede modificar el expediente bajo la
supervisión del doctor. Por otro lado, la herramienta consulta de pacientes despliega todas los
ecocardiogramas y electrocardiogramas en la computadora táctil, ya que es muy usual dicha
preferencia por los usuarios del hospital mencionado. Mientras que las tablet solo contienen las
anotaciones médicas.
Al terminar las visitas tanto Sandy como Isaac continúan con sus actividades, por tal motivo
la herramienta de consulta de pacientes 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 nutriólogo.
Este escenario aborda todas las dimensiones del contexto de uso de los sistemas colaborativos.
La adaptación al grupo de colaboradores se implementa al proveer información relacionada
con los estratos de los colaboradores en el hospital, e.g., el Dr. Isaac tiene el control que permite
la intervención de Alice dentro del sistema del hospital. También adapta a las preferencias de
los usuarios,e.g., el Dr. Isaac decidió que el sistema le provea de información de los expedientes,
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 que
esta dimensión ha sido llevada a cabo mediante la herramienta de consulta de pacientes al
detectar el espacio de almacenamiento y los visores disponibles.
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 la pantalla de los dispositivos móviles de los colaboradores el expediente del
paciente que están actualmente visitando) y el tiempo (proveer la información una hora antes
de la reunión).
4.8.3
Herramienta administrador de contenidos vı́a NFC
Este escenario considera dos herramientas, administración de contenidos y sistema de consultas
de pacientes. En este caso solo se ha implementado la primera, la cual permite facilitar a un
grupo de colaboradores la información que se tratará 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 necesaria
sobre la reunión.
Capı́tulo 4
119
Los requerimientos funcionales del administrador de contenidos vı́a NFC se listan 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 documentos que son relevantes a la misma.
2. Permitir que un colaborador pueda grabar en una etiqueta NFC la información relacionada
a una reunión.
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. Ejecutarse automáticamente cuando un colaborador inicie su sesión a través de una etiqueta NFC y haya información sobre una reunión grabada en dicha etiqueta. Detectar
qué tipos de formato de documentos son soportados por las herramientas de visualización
instaladas en el dispositivo.
5. Iniciar la descarga de los documentos que es necesario revisar durante una reunión. Durante la solicitud de documentos, se debe indicar qué tipos de formato son soportados, de
tal manera que los documentos a descargar sean en un formato soportado.
6. Mostrar en la interfaz de usuario de la aplicación un ı́cono por cada documento descargado
y permitir la apertura de dicho documento al hacer clic sobre su ı́cono.
Los requerimientos no funcionales del administrador de contenidos vı́a NFC son los siguientes:
1. Habilitar el adaptador de red inalámbrico WI-Fi, si éste se encuentra deshabilitado.
2. Permitir la apertura de los documentos descargados.
3. No permitir la transmisión de información a dispositivos de usuarios que no estén registrados.
Las variables contextuales en la herramienta administrador de contenidos vı́a NFC son las
siguientes: 1) tiempo, 2) visores disponibles y 3) espacio de almacenamiento.
La variable contextual “tiempo” determina la información que es susceptible de ser descargada. Por otro lado, la variable “visores disponibles” permite conocer los visualizadores
disponibles en el dispositivo del usuario y de esta forma determinar el formato de los documentos que podrán ser desplegados. Finalmente, la variable “espacio de almacenamiento”
determina qué versión de los documentos podrán ser descargados; previamente deben estar
registrados dos o más versiones del mismo documento.
120
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 la adaptación de esta
herramienta:
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: la etiqueta transfiere al dispositivo
del usuario la información referente a la reunión en curso. A continuación, se ejecuta el
módulo de lectura de la aplicación, cuya interfaz de usuario es adaptada de acuerdo a la
información recibida, i.e. muestra la lista de puntos a tratar en la reunión e información
adicional correspondiente a cada uno de ellos. Finalmente, el módulo de lectura inicia la
descarga de los documentos a revisar durante la reunión.
2. El módulo de lectura de la aplicación detecta qué tipos de formatos de documento son soportados por las herramientas de visualización del dispositivo:
durante la solicitud de descarga de cada documento, el módulo de lectura indica los formatos de documento soportados por el dispositivo, de tal manera que el documento a
descargar tenga un formato soportado (si está disponible).
3. Termina la descarga de los documentos a revisar durante la reunión: la interfaz
de usuario de la aplicación muestra, junto a cada tema de la reunión, los documentos
asociados a cada uno. Por medio de un clic sobre uno de los ı́conos se puede visualizar el
contenido del documento correspondiente.
4.9
Escenario 7: Notificaciones multi-modales
Este escenario provee notificaciones de diversas modalidades para que dichos avisos se adapten
al contexto.
4.9.1
Preámbulo
La multi-modalidad nos permite dar a conocer la llegada de información de diferentes formas
dependiendo del tipo de información a notificar, del lugar en donde se encuentra ubicados los
colaboradores e incluso de las personas a nuestro alrededor. Las notificaciones multi-modales
más usadas en los celulares son por: sonido, 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:
Capı́tulo 4
121
• la relevancia de la información, e.g., la notificación del cambio de medicamento de un
paciente hospitalizado es más importante para una enfermera que recibir la notificación
de un dispositivo cercano que permite hacer video-llamadas;
• la actividad del colaborador que origina la notificación y la del colaborador que recibe la
notificación son importantes;
• el lugar fı́sico en donde se encuentra el receptor de la notificación.
4.9.2
Sandy, Alice e Isaac pertenecen al 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 con fecha lı́mite caducada que no podı́an resolver. La actividad
mencionada es importante, ya que es parten de los avances a presentar frente a los clientes.
Los miembros del grupo de desarrollo utilizan un sistema que informa mediante notificaciones
acerca de las modificaciones y las actividades concluidas en las que está participando el grupo.
Antes de emitir la notificación, el sistema determina el modo de la notificación considerando
las siguientes caracterı́sticas: 1) la actividad actual tanto de Alice como de Sandy corresponde
a exponer los avances del proyecto, 2) las colaboradoras se encuentran en una sala de juntas con
personas ajenas al proyecto, 3) la conclusión de la actividad de avances del proyecto ya que esta
actividad 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 es utilizada por 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 la recibieron 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 hace la
notificación mediante la computadora que tiene en uso Isaac en su oficina-, la selección de dicho
dispositivo se debe a la poca relevancia de la actividad ası́ como la fecha lı́mite de la actividad.
Isaac quiere saber sobre los resultados de la presentación a los clientes, por tal motivo él
organiza una reunión en su oficina mediante una agenda colaborativa. 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
122
temporalmente no están desarrollando ninguna 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 respectivas oficinas para continuar trabajando en las actividades asignadas. Sandy se encarga de los diagramas
de clase, ası́ que ella no requiere 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 cómputo 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 decida 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.
Este escenario se adapta a todo contexto de uso de los sistemas colaborativos. 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
Sı́ntesis
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
colaborativos. 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 la instancia del sistema de dicho usuario se ve afectado sin modificar las instancias
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 observado y observador.
El contexto de uso de los sistemas colaborativos afectan a todos los colaboradores que están
conectados al sistema, e.g., en el escenario “mejoramiento del trabajo colaborativo” se permite
ligar objetos compartidos, los cuales han sido creados desde diferentes aplicaciones, mediante
Capı́tulo 4
123
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 colaborativo. Dichas adaptaciones se hacen al grupo de
colaboradores al considerar sus preferencia relacionadas a los medios de adaptación (cf. Sección
4.6), dependiendo del rol se puede mostrar los iconos relacionados a su rol (cf. Sección 4.4),
información necesaria dependiendo de la actividad en curso (cf. Sección 4.8) o en otras ocasiones ocultar dicha información que puede ser confidencial (cf. Sección 4.7). Otra adaptación
al colaborador es presentar notificaciones usando diferentes modalidades dependiendo de la
actividad o del entorno en donde se ubica (cf. Sección 4.9).
Dichos escenarios 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 de si los colaboradores tienen una cámara en uso, de otra manera
no vale la pena ofrecer el servicio (cf. Sección 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. Sección 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 de si el trabajo es co-localizado o distribuido (cf. Sección 4.5) o la detección de la
presencia de una persona no autorizada para ver información restringida (cf. Sección 4.7).
Algunas de las propuestas mencionadas en los escenarios han sido implementadas en las
herramientas desarrolladas. Por ejemplo, adaptar los iconos dependiendo del rol del colaborador
(cf. Secciones 4.4.3 y 4.3.3), de si el trabajo es co-localizado o distribuido (cf. Secciones 4.5.3,
4.8.3 y 4.4.3).
Uno de tantos problemas detectados y no resueltos en este tema de investigación se refiere
a qué funcionalidades debe ofrecer una aplicación colaborativa cuando detecte que un grupo
de colaboradores trabajan de manera co-localizada, usan un dispositivo compartido, e.g., un
pizarrón interactivo, y dichos colaboradores tienen roles diferentes. La aplicación colaborativa
debe decidir qué funcionalidades de la aplicación mostrar. El sistema puede resolver de varias
maneras el problema anterior, las cuales son:
• combinar las funcionalidades dados los roles de los colaboradores, i.e., unir los ı́conos que
tienen acceso cada uno, sin duplicar estos;
• mostrar en el pizarrón interactivo las funcionalidades que coinciden, dejando en sus dispositivos personales, en caso de tener estos, 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 los colaboradores las opciones por medio de una meta-interfaz de usuario para que ellos elijan la
124
más adecuada.
Capı́tulo 5
Diseño del marco XARE
En este capı́tulo se describen los diseños horizontal y vertical del marco XARE. El diseño
vertical, que se explica 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 soportes contextuales en sus aplicaciones.
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
estos mecanismos contienen los parámetros de entrada necesarios, las clases involucradas, ası́
como los elementos susceptibles de ser modificados.
El diseño horizontal se aborda en la sección 5.3 y se refiere a las capas del marco XARE, el
cual propone adaptar los sistemas colaborativos a diferentes contextos de uso. Este marco surge
a partir de la creación y el análisis de los escenarios mostrados en el capı́tulo 4, los cuales nos
permitieron identificar en una primera versión las tres capas sin mucho detalle. Dicha versión
considera los percutores de adaptación (remodelación y redistribución) y la participación de
los colaboradores durante el proceso de adaptación (meta-interfaz con o sin negociación), y
evita en todo momento la pérdida de sus contribuciones (recuperación del sistema). Posterior
a la implementación de algunas aplicaciones se identificaron los modulos de Disponibilidad,
Actividad Actual y Proximidad Lógica pertenecientes a la capa de Detección. Otra contribución
importante fue la incorporación del módulo referente al espacio de Trabajo Privado y Público.
Finalmente, en la sección 5.4 se presenta una sı́ntesis del presente capı́tulo.
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 [Buvaĉ et al., 1995],
125
126
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 soporte contextual mediante lenguajes de programación orientado a objetos. Además, estos
diagramas han sido utilizados para llevar a cabo la modelación visual de conceptos del mundo
real, con el fin de reducir la complejidad y la carga cognitiva durante la etapa de diseño de
sistemas [Henricksen et al., 2002, Derntl and Hummel, 2005].
5.1.1
Contexto de uso de los sistemas colaborativos
Como se mencionó en el capı́tulo 4, el contexto de uso de los sistemas colaborativos se forma de
los componentes grupo de colaboradores, conjunto de plataformas y entorno común.
En la Figura 5.1, se muestra que el contexto de uso de los sistemas colaborativos ha sido
modelado mediante el patrón de diseño Decorator, el cual permite definir dinámicamente
nuevos contextos de uso (clase abstracta ContextOfUse) para hacer que un sistema colaborativo
se adapte a cambios contextuales (clase abstracta AdaptativeGroupwareSystem). Gracias a
la estructura de clases abstractas y concretas del patrón de diseño Decorator, dicho sistema
colaborativo no necesita ser modificado por completo. De este modo, es posible que cualquier
sistema colaborativo no adaptativo (clase ConcreteGroupwareSystem) se vuelva consciente de
varios contextos de uso (clases ContextOfUse 1 ... ContextOfUse n).
Los diferentes contextos de uso pueden incluir todos o algunos de los componentes 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 estructural provee
a los programadores un soporte flexible de desarrollo que les permite enriquecer sus sistemas
colaborativos con capacidades de adaptación, involucrando algunos o todos estos componentes
(clases GroupOfCollaborators, SetOfPlatforms y CommonEnvironment).
La Figura 5.1 muestra un grupo de colaboradores (clase GroupOfCollaborators) que está
compuesto por al menos un colaborador (clase Collaborator) 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 refieren 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 por los estados (atributo state) presente o ausente, pero si el colaborador está presente,
él puede estar ocupado, accesible, contactable si es posible y disponible. Un colaborador puede
mostrar simultáneamente diferentes niveles de disponibilidad a sus colegas dependiendo (cf.
Mecanismo de disponibilidad en la sección 5.2.2) de:
Capı́tulo 5
127
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
Has
PhysicalPlace
Calculates
CommonEnvironment
1..*
Action
1..*
UserInterface
1..*
Workspace
1..*
Has
1..*
Setting
Has
PrivateWorkspace
SharedWorkspace
Runs
*
*
DistributedSetting
HybridSetting
PrivateObject
SharedObject
1..*
ColocalizedSetting
RichDesktop
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()
Componente propuesto en el dominio de los sistemas mono-usuario
Componente propuesto en el dominio de los sistemas colaborativos
Extensión propuesta en esta tesis
Figura 5.1: Contexto de uso de los sistemas colaborativos
128
• la similitud (atributo similarity) entre su actividad actual y las actividades en curso o
potenciales de los colaboradores 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
coherentes (clase Action) sobre un objeto compartido (clase SharedObject) o privado (clase
PrivateObject) que tienen un objetivo común (atributo goal). La similitud de actividades es
medida en términos de los objetos compartidos que están siendo manipulado por los colaboradores y de sus actividades actuales o potenciales (atributo sortActivity). La similitud entre
las actividades de dos colaboradores puede tomar alguno de los siguientes valores: muy similar,
similar, más o menos similar, poco similar, muy poco similar y no similar (cf. Mecanismo de
similitud 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 por sus colegas 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 sus dispositivos
actuales (clase ComputerDevice) i.e., los que está utilizando para lograr su actividad en
curso, y
2. su estado de disponibilidad (atributo state de la clase Availability) o la similitud
entre su actividad actual y las actividades en curso o potenciales de los colaboradores que
quieren contactarlo (relación hasSimilarity de la clase Activity).
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 ofrece
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
realiza sus aportaciones personales (clase PrivateObject). También, dicho colaborador puede
compartir con su grupo de colegas un espacio común (clase SharedWorkspace), donde cada
uno publica sus contribuciones. Dicho espacio de trabajo común provee consciencia de grupo
(clase GroupAwareness) por medio de una barra de colaboradores (clase CollaboratorBar).
Dependiendo del rol actual del colaborador, su desktop (clase RichDesktop) provee aplicaciones colaborativas que facilitan las actividades correspondientes a su rol (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
Capı́tulo 5
129
SharedObject). Gracias al desktop, una aplicación colaborativa puede estar relacionada con
otras por medio de sus respectivos objetos compartidos (clase Link). Un objeto compartido
es implementado siguiendo el patrón de diseño Composite porque el marco XARE pretende
soportar el dominio de aplicación de edición colaborativa de documentos.
Cada instancia de una aplicación colaborativa es capaz de enviar notificaciones a otras instancias (clase Notification), con la finalidad de que los colaboradores posean la información
necesaria para realizar sus actividades (cf. Figura 5.1). Dichas notificaciones pueden ser enviadas usando diferentes modalidades (clase Modality), e.g., sonido, vibración o cuadros de
texto, dependiendo tanto de la actividad en curso como de la ubicación fı́sica del receptor. La
comunicación (clase Comunication) entre las instancias de una aplicación les permite obtener
información nueva o almacenada.
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́nea (clase ImmediateForm), la cual se refiere a transmitir la información en el
momento justo en que es generada, y
2. periódica (clase PeriodicForm), la cual notifica la información en momentos predefinidos.
El entorno común (clase CommonEnvironment) es aquel donde toma lugar la colaboración, la
cual involucra diversas variables contextuales, e.g., los lugares fı́sicos (clase PhysicalPlace) en
donde los colaboradores están interactuando. Por lo tanto, tres configuraciones de trabajo son
posibles:
1. todos los colaboradores están distribuidos, i.e., cada uno está 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 co-localizados,
mientras otros están distribuidos.
Para determinar si el grupo de colaboradores está distribuido y/o co-localizado, se debe detectar la presencia de los colaboradores en lugares especı́ficos (e.g., una sala de juntas) mediante
hardware o software. La detección por hardware se hace por medio de sensores (clase Sensor),
e.g., sensores infrarrojos. En cambio, la detección de colaboradores por software se lograr al
usar aplicaciones dedicadas, e.g., reconocimiento de rostros.
La implantación de un entorno multi-dispositivo y multi-usuario implica que cada colaborador puede no solo tener la posibilidad de interactuar con otros colaboradores, sino también
130
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 es
desplegado (clase PrivateWorkspace), y un teléfono inteligente que actúa como control remoto
de un pizarrón electrónico (clase SharedWorkspace), donde el espacio de trabajo compartido
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. En este trabajo de investigación se maneja
el concepto de “objeto abstracto” (clase AbstractObject) para referirnos a la información
electrónica que es utilizada, generada y compartida por los colaboradores. La información
electrónica se refiere a: audio (clase Audio), video (clase Video), imágenes (clase Image) y
documentos de texto (clase Text), e.g., manuales, reportes, artı́culos, ası́ como información
generada desde la mensajerı́a instantánea que se ejecuta en cualquier dispositivo de cómputo.
5.1.2
Componente observador
El componente contexto de uso (clase ContexOfUse) está provisto de un componente observador
(clase Watcher), el cual es responsable de observar los cambios contextuales con el fin de
ejecutar los percutores de adaptación (clases Remodelation y Redistribution), definir tanto
la granularidad del estado de recuperación (clase Recovery) como la granularidad de adaptación
(clase Adaptation) y detectar cuándo se está relacionando un objeto compartido con otro (clase
Link) de manera implı́cita o explicita (cf. Figura 5.2).
Varias de las clases que ejecuta la clase Watcher pueden ofrecer varios tipos de metainterfaces 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()). Dichas meta-interfaces están a cargo de informar los
cambios que deben ejecutarse en los espacios de trabajo compartido (clase SharedWorkspace)
y privado (clase PrivateWorkspace).
Como se mencionó en la
[Vanderdonckt, et al., 2008] denota:
sección
2.2
del
capı́tulo
2,
la
redistribución
“ 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”.
La clase Redistribution tiene como finalidad redistribuir la interfaz de usuario de una
Capı́tulo 5
131
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 componente observador
aplicación colaborativa en un conjunto de dispositivos, los cuales pueden pertenecer a un colaborador (clase Collaborator) o un grupo de colaboradores (clases GroupOfCollaborators).
La clase Watcher está encargada de llamar a la clase Redistribution, cuando detecta cambios
en la configuración del grupo y/o el ingreso o la salida de un dispositivo de cómputo.
Como se mencionó en la sección precedente, la configuración del grupo se refiere a tres formas
posibles de trabajo de los colaboradores: 1) co-localizada (clase ColocalizedSetting), 2)
distribuida (clase DistribuitedSetting) e 3) hı́brida (clase HybridSetting). Para ejecutar el
percutor de redistribución, la clase Watcher considera algunos cambios contextuales, los cuales
son ejemplificados a continuación:
• Suponga que un grupo de colaboradores trabaja en una sala de juntas, la cual está
equipada con algunos dispositivos de carácter público, e.g., un pizarrón electrónico. Cada
colaborador dispone de un dispositivo móvil, e.g., una tablet o un teléfono inteligente.
Al momento en que la clase Watcher detecta el conjunto de dispositivos en uso y la
configuración del grupo (en este caso, co-localizada), esta clase ejecuta el percutor de
redistribución (clase Redistribution) para que la interfaz de usuario de la aplicación colaborativa sea repartida entre dichos dispositivos, e.g., los colaboradores podrı́an tener su
espacio privado (clase PrivateSpace) en sus dispositivos móviles, mientras que el espacio
compartido (clase SharedWorkspace) podrı́a ser desplegado en el pizarrón electrónico.
132
• Considere que el mismo grupo de colaboradores continúa trabajando de manera colocalizada, pero uno de los integrante quiere utilizar dos dispositivos a la vez para interactuar con la aplicación colaborativa. La clase Watcher detecta el ingreso del nuevo
dispositivo y, en consecuencia, ejecuta la redistribución (clase Redistribution) de la
instancia de aplicación de dicho colaborador. En este caso, la interfaz de usuario que
muestra su espacio de trabajo privado pasa de un estado centralizado a uno redistribuido.
• Posteriormente, todos los colaboradores salen de la sala de juntas para dirigirse a sus
respectivas oficinas, ası́ que la clase Watcher detecta el cambio de configuración grupal (de
co-localizada a distribuida). En este caso, dicha clase ejecuta el percutor de redistribución
(clase Redistribution) para replicar el espacio de trabajo compartido, desplegado en el
pizarrón electrónico, en los dispositivos móviles de los colaboradores. En consecuencia,
la interfaz de usuario del espacio compartido cambia de un estado centralizado a uno
replicado, ya que cada colaborador tiene en su dispositivo móvil tanto su espacio privado
como el espacio compartido.
• Tiempo después, algunos de los colaboradores deciden reunirse nuevamente en la sala de
juntas para discutir un tópico en especı́fico, ası́ que algunos continúan trabajando en sus
respectivas oficinas, mientras otros trabajan cara a cara (configuración hı́brida). En consecuencia, la clase Watcher ejecuta el percutor de redistribución (clase Redistribution)
al momento de detectar este cambio en la configuración del grupo. En este caso, la interfaz de usuario de espacio de trabajo compartido se reconcentra en el pizarrón electrónico,
ya que este es accessible a todos los colaboradores que están co-localizados.
La forma de trabajo de un grupo no necesariamente debe partir de una configuración colocalizada para después pasar a una redistribuida y finalizar con una hı́brida, sino que la configuración del grupo también puede empezar siendo redistribuida o hı́brida, para posteriormente
pasar a alguna de las tres configuraciones mencionadas.
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 una interfaz de
usuario. Los componentes susceptibles a remodelar son los siguientes (cf. sección 4.2):
• el espacio de trabajo privado de un colaborador dependiendo su rol (clase Role), cuando
este ingrese a su desktop;
• el espacio de trabajo compartido al detectar a un grupo de colaboradores trabajando co-localizadamente (clase ColocalizedSetting) o distribuidamente (clase
DistribuitedSetting);
Capı́tulo 5
133
• información, e.g., ocultar información restringida al detectar a una persona ajena al grupo
de colaboradores o mostrar información relevante dependiendo del lugar, del momento y
de las necesidades del colaborador;
• los medios de contacto y la disponibilidad de un colaborador (clases Availability y
ContactMeans) dependiendo de los colaboradores implicados.
La clase Watcher ejecuta la clase Remodelation al detectar algunos de los siguientes cambios
contextuales:
• inicio de sesión por parte de un colaborador;
• identificación de la configuración del grupo (distribuida, co-localizada o hı́brida);
• detección de una persona, ajena al grupo de trabajo, que está muy cerca del área de
despliegue de información;
• determinación del momento en el que se debe enviar información relacionada con la actividad de un colaborador;
• cálculo de la disponibilidad un colaborador 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 que los usuarios deben realizar para continuar su actividad una vez finalizado
el proceso de adaptación de un sistema interactivo. 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 compartidos y privados (clases SharedWorkspace y PrivateWorkspace, respectivamente), los cuales mantienen
el trabajo en proceso. La clase Watcher ejecuta la clase Recovery antes y después de llevar a
cabo la adaptación al nuevo contexto de uso.
En la sección 2.3 del capı́tulo 2 se mencionó que la granularidad de la adaptación 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 los percutores de remodelación y/o redistribución.
Finalmente, la clase Link tiene como objetivo relacionar una aplicación con otra por medio
de sus objetos compartidos. La clase Watcher ejecuta la clase Link cuando detecta que un
colaborador relaciona un objeto de una aplicación con un objeto de otra aplicación por medio
de una hiperliga.
134
5.2
Mecanismos del marco XARE
El marco XARE ofrece a los desarrolladores varios mecanismos que realizan los cálculos necesarios para llevar a cabo la adaptación al contexto. Algunos de esos cálculos se efectúan mediante
reglas difusas.
5.2.1
Mecanismo de similitud de actividades
La similitud de actividades involucra a un colaborador observado y a un observador. Los
parámetros necesarios para calcular la similitud de actividades corresponden a: 1) las actividades potenciales y actuales que están siendo realizadas por dichos colaboradores y 2) los
objetos compartidos que están procesando mediante sus acciones.
El grado de similitud entre las actividades de los colaboradores observador y observado puede
tomar los siguientes valores:
1. muy similares, cuando están llevando a cabo las mismas acciones sobre el mismo objeto
compartido;
2. similares, cuando están ejecutando las mismas acciones en diferentes objetos relacionados
(e.g., una figura y el correspondiente párrafo que describe esta);
3. más o menos similares, cuando están ejecutando las mismas acciones en diferentes objetos
no relacionados (e.g., modificación de diferentes secciones);
4. poco similares, cuando están ejecutando diferentes acciones sobre el mismo objeto compartido;
5. muy poco similares, cuando están ejecutando diferentes acciones sobre diferentes objetos
relacionados;
6. no similares en cualquier otro caso.
En la tabla 5.1 se ejemplifica la forma de asignar los diferentes grados de similitud entre
las actividades del colaborador un y las de sus colegas u1 , u2 , u3 , u4 , u5 y u6 . El mecanismo
toma en cuenta las acciones actuales que están llevando acabo estos colaboradores y los objetos
que están manipulando por medio de tales acciones. Dicho mecanismo también considera las
acciones y los objetos que son potencialmente accesibles al colaborador un . De está forma,
el colaborador un tiene actividades muy similares y similares a las de los colaboradores u1
y u2 , respectivamente durante una sesión de trabajo donde los colaboradores u1 y un están
modificando concurrentemente el objeto compartido o, mientras que el colaborador u2 está
modificado el objeto compartido p, el cual está relacionado con el objeto o.
Capı́tulo 5
135
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
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
ciones sobre el objeto o
Potencialmente más o
menos similares
u5 está leyendo el objeto p
Muy poco similares
u6 está leyendo el objeto q
No similares
Potencialmente
similares
poco
poco
Tabla 5.1: Similitud entre las actividades de dos colaboradores
Sin embargo, la situación previamente descrita puede ser completamente diferente en una
sesión subsecuente o incluso en la misma sesión, debido al carácter dinámico del trabajo colaborativo. 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 mismas actividades mencionadas, la actividad del colaborador un no es
similar a las de los colaboradores u1 y u2 .
Las clases utilizadas por este mecanismo son Activity y Action. La primera clase permite
obtener el conjunto de actividades asociadas a ambos colaboradores (observado y observador) y
calcular la similitud de actividades mediante el método HasSimilarity. Por su parte, la clase
Action permite identificar sobre qué objeto compartido están trabajando dichos colaboradores
en un momento dado para inferir la actividad en curso. Este mecanismo es requerido por los
mecanismos de disponibilidad y de medios de contacto para llevar a cabo sus propios cálculos.
136
5.2.2
Mecanismo de disponibilidad de un colaborador
Este mecanismo es responsable de determinar la disponibilidad de un colaborador observado,
cuyo valor varı́a de un observador a otro. El colaborador observado puede ser percibido como
presente o ausente durante una sesión de trabajo y, en caso de que 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 mecanismo:
1. ocupado: posibilita al colaborador observado de informar que no quiere ser interrumpido;
2. accesible: permite al colaborador observado indicar que, aún si está ocupado, puede ser
interrumpido si es necesario y tan pronto como pueda responderá;
3. contactable si es posible: el colaborador observado admite que puede ser interrumpido, pero no asegura una rápida respuesta;
4. disponible: permite al colaborador observado indicar que puede ser contactado en
cualquier momento.
Al igual que la similitud de actividades, la disponibilidad se calcula tomando en cuenta la
siguiente información del colaborador observado y del observador:
1. la similitud entre la actividad en curso del colaborador observado y las actividades potenciales y actuales del observador y
2. la fecha lı́mite de la actividad en curso (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 considerar 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, sin importar si la fecha lı́mite de la actividad de esté último es cercana o distante.
En está situación, el mecanismo favorece la posibilidad de mantenerse contactable por personas
relacionadas por la similitud de sus actividades.
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
contactable si es posible, cuando la fecha lı́mite de la actividad de este último sea cercana,
o accesible, cuando dicha fecha sea distante. En el caso de que dichos colaboradores estén
ejecutando actividades muy poco similares o diferentes, pero una de las actividades potenciales
del observador es muy similar o similar a la actividad actual del colaborador observado, el
Capı́tulo 5
137
Fecha lı́mite
Disponibilidad del colaborador observado
Cercana
...
Distante
La actividad actual del observador es similar o muy
similar a la del colaborador observado
Accesible
Accesible
La actividad actual del observador es más o menos
similar o poco similar a la del colaborador observado
Contactable
si es posible
Accesible
La actividad actual del observador es muy poco
similar o no es similar a la del colaborador observado, pero una de sus actividades potenciales es similar
o muy similar
Contactable
si es posible
Contactable
si es posible
La actividad actual del observador es muy poco
similar o no es similar a la del colaborador observado, pero una de sus actividades potenciales es más o
menos similar o poco similar
Ocupado
Contactable
si es posible
Las actividades actuales y potenciales del observador son
muy poco similares o no son similares a la actividad actual del colaborador observado
Ocupado
Ocupado
Tabla 5.2: Estados de disponibilidad de un colaborador percibidos por sus colegas
observador percibirá la disponibilidad del colaborador observado como contactable si es
posible, sin importar cuando termina la actividad de este último. En estas situaciones, el
mecanismo facilita el contacto entre los colaboradores, aunque en diferentes grados, ya que la
probabilidad de estar relacionados en un momento dado es alta.
Cuando las actividades en curso tanto del colaborador observado como del observador son
muy poco similares o no similares, pero sus actividades serı́an más o menos similares o poco
similares en un momento dado, el mecanismo solo facilita el contacto cuando la fecha lı́mite de
la actividad del colaborador observado es distante. De otra manera, el observador percibirá al
colaborador observado como ocupado. Finalmente, si los colaboradores implicados no tienen
en común actividades actuales ni potenciales, el contacto no es posible. Sin embargo, esté
mecanismo puede ser configurado por cada colaborador, con el fin de proveer opciones más
flexibles. Por ejemplo, este mecanismo puede permitir 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 estos colaboradores están trabajando en el mismo proyecto.
138
Aún si los subestados de disponibilidad están determinados por el mecanismo propuesto, el
colaborador observado puede modificarlos cuando lo requiera.
Este mecanismo usa las clases Availability y Activity. En particular, este mecanismo
forma parte de la primera clase, Availability. La clase Activity proporciona la similitud
entre las actividades de los colaboradores involucrados, ası́ como la fecha 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, el marco
XARE propone un mecanismo para establecer dichos medios de manera automática. Como
se muestra en la Figura 5.3, este mecanismo hace uso de los mecanismos descritos en las
dos subsecciones 5.2.1 y 5.2.2. Nuevamente, debemos hacer la distinción entre colaborador
observado y observador, dado que uno de estos mecanismos requiere de esta diferenciación.
El primer mecanismo está a cargo de determinar la similitud entre las actividades en curso de
dos colaboradores. Este mecanismo toma, como parámetros de entrada, la actividad en curso
de cada colaborador (cf. actividad a y actividad b de la Figura 5.3), la cual está definida por
la acción que cada colaborador está ejecutando (cf. acción a y acción b de la Figura 5.3) y el
objeto que está siendo manipulado por dicha acción (cf. objeto a y objeto b de la Figura 5.3).
Como se mencionó en la sección 5.2.1, este mecanismo da como resultado un valor difuso de
similitud (e.g., muy similar, más o menos similar o no similar).
El segundo mecanismo es responsable de determinar la disponibilidad de un colaborador,
cuyo valor varı́a de un observador a otro, dependiendo de la similitud entre las actividades en
curso del colaborador observado y del observador, ası́ como de la fecha lı́mite de la actividad del
primero. El parámetro de entrada correspondiente a la fecha lı́mite de la actividad es también
un valor difuso (e.g., cercana o distante). Como resultado, este mecanismo crea un objeto de
la clase Availability, el cual está relacionado con un objeto de la clase Collaborator que
representa al colaborador observado. Como se mencionó en la sección 5.2.2, la disponibilidad de
un colaborador es también un valor difuso (e.g., ocupado, contactable si es posible o accesible).
Con base en estos dos mecanismos previamente mencionados, el marco XARE propone un
mecanismo que permite a los colaboradores definir sus medios de contacto. Este mecanismo
acepta diversos conjuntos de parámetros de entrada, aunque un parámetro común de todos estos
conjuntos se refiere a las caracterı́sticas de software y hardware de los dispositivos utilizados por
los colaboradores implicados en un proceso de comunicación. Por lo tanto, cada colaborador
puede configurar su propia instancia de este mecanismo con base en los siguientes parámetros
de entrada:
Capı́tulo 5
139
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
Acción:
acción_b
Actividad:
tiene
actividad_b
ac
tiv
ida
d_
actividad_b
a
Mecani
smo: Similitud
ud
ilit o y
sim rvad or)
d
se
(ob serva
b
o
(o sim
ob bser ilitu
se va d
rv do
ad y
or
)
Mecanis
mo:
Medio de contacto
disponibilidad del usuario
observado
Mecanismo:
Disponibilidad
tiene
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 los medios de contacto de un colaborador
1. los subestados de disponibilidad del colaborador;
2. la similitud entre las actividades del colaborador y las de sus colegas;
3. los medios de contacto preferidos del colaborador;
4. la proximidad lógica entre el colaborador y sus colegas en el espacio de trabajo compartido
de una aplicación colaborativa (cf. sección 5.2.6).
La salida de este mecanismo es la creación de un objeto de la clase ContactMeans que
contiene una lista de los medios de contacto asociados al colaborador observado, quién está
representado por un objeto de la clase Collaborator. La lista resultante de medios de contacto
140
será visualizada por un observador dado. Por cada uno de los medios de contacto de esta lista,
el mecanismo asegura que los dispositivos de los colaboradores involucrados cuentan con las
caracterı́sticas de software y hardware necesarias para establecer la comunicación entre ellos
(clases Hardware y Software).
5.2.4
Mecanismo de ocultar, sustituir y mostrar componentes
El mecanismo para ocultar, sustituir y mostrar componentes en una interfaz de usuario tiene
como objetivo modificar la visibilidad de dichos componentes dependiendo de algunos factores,
e.g., dependiendo del rol del colaborador, solo se muestran los iconos de acceso directo a las
aplicaciones útiles a dicho rol o en función del espacio libre en el disco local de un dispositivo se
puede almacenar la información local o remotamente. Este mecanismo (cf. Figura 5.4) acepta
dos parámetros de entrada:
1. el rol de un colaborador, y
2. el conjunto de dispositivos disponibles, los cuales se refieren a aquellos que pertenecen a
los colaboradores participantes en una sesión y servidores.
Para explicar mejor el mecanismo esquematizado en la Figura 5.4, supongamos que el usuario
colaborador a juega el papel de rol a e ingresa a su escritorio desktop a mediante la computadora dispositivo a. Este mecanismo debe mostrar al colaborador a solo los componentes (e.g.,
aplicación a) que son adecuados para desempeñar el rol a utilizando el dispositivo a. En el
caso de componentes que representan una funcionalidad, e.g., ı́cono de guardar o imprimir, se
verifica si el dispositivo a puede ofrecer directamente dicha funcionalidad o requiere la ayuda
de otros dispositivos, e.g., el dispositivo b, los cuales podrı́an no pertenecer al colaborador a.
Deduciendo del ejemplo anterior, las principales clases involucradas en este mecanismo son:
Role, ComputerDevice y Desktop. Mediante la clase Role es posible obtener el rol actual de
un colaborador, el cual está representado por un objeto de la clase Collaborator. La clase
ComputerDevice está relacionada con las clases Collaborator, Hardware y Software con el fin
de proporcionar las caracterı́sticas de hardware y software de los dispositivos en uso de un colaborador y además, cuando sea necesario. La clase ComputerDevice ofrecerá las caracterı́sticas
de otros dispositivos disponibles que pueda utilizar dicho colaborador. La clase Desktop pone
a disponibilidad del colaborador en cuestión aquellas aplicaciones colaborativas (representadas
por objetos de la clase AplicaciónColaborativa) que son útiles para el rol actual del colaborador. Aunque no se ilustra en la Figura 5.4, este mecanismo también pueden modificar algunas
funcionalidades especı́ficas de las aplicaciones disponibles al colaborador, e.g., algunos de los
iconos ofrecidos por una aplicación pueden ser ocultados por no estar relacionados al rol actual
del colaborador.
Capı́tulo 5
141
tiene
tiene
Colaborador:
colaborador_a
Rol:
rol_a
rolActual
tiene
EntornoComún
RichDesktop:
desktop_a
mod
ifica
rCom
pone
nte()
tiene
Mecanismo:
Ocultar/Mostrar
AplicaciónColaborativa:
aplicaciónColaborativa_a 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 componentes y/o funcionalidades
5.2.5
Mecanismo para la creación de referencias deı́cticas
Este mecanismo permite a los colaboradores crear referencias deı́ticas desde una aplicación
hacia los objetos compartidos de otra aplicación, con la finalidad de mantener el contexto de
dichos objetos. La funcionalidad de deixis (cf. Figura 5.5) ofrecida por este mecanismo genera
como resultado ligas de hipertexto entre una palabra clave de la mensajerı́a instantánea y un
objeto compartido del editor colaborativo. Gracias a esta funcionalidad, los colaboradores no
necesitan copiar objetos desde el editor colaborativo hacia la mensajerı́a instantánea cuando
en el curso de una conversación se hace referencia a ellos.
El mecanismo de referencias deı́ticas recibe dos parámetros de entrada por parte de un
colaborador:
1. palabras deı́cticas, tales como esta figura, la siguiente sección, este párrafo, esas referencias bibliográficas o aquı́, las cuales son seleccionadas desde la mensajerı́a instantánea;
142
Colaborador:
colaborador_a
tiene
Rol:
rol_a
tiene
EntornoComún
RichDesktop:
desktop_a
tiene
mensajeríaInstantánea
tiene
editorColaborativo
tien
e
Mecanismo:
Deixis
tiene
ObjetoCompartido:
palabraDeíctica
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: Mecanismo de referencias deı́ticas
2. un objeto compartido como un tı́tulo, un párrafo, una frase, una palabra, una referencia bibliográfica, una figura o una sección; dicho objeto es seleccionado desde el editor
colaborativo.
En la Figura 5.5 se puede observar al usuario colaborador a, quien trabaja en su escritorio desktop a en donde está usando las aplicaciones mensajerı́aInstantánea y editorColaborativo. En este caso, dicho colaborador crea una referencia deı́ctica entre una palabra clave
palabraDeı́ctica y un objeto compartido párrafo.
Cuando el colaborador dé clic sobre la referencia deı́ctica de la mensajerı́a instantánea, se
debe mostrar el objeto referenciado a la mitad del área de despliegue del editor colaborativo.
En caso de que el objeto referenciado sea un texto, este debe cambiar de color para ser resaltado; en cambio, si el objeto referenciado es una imagen, esta debe ser puesta en evidencia
mediante un recuadro coloreado. Además, el escritorio debe ofrecer la opción de crear una
replica en el pizarrón multi-usuario de la imagen referenciada en el editor colaborativo. El
escritorio mantiene un identificador y la ubicación de la imagen dentro del documento origen.
Capı́tulo 5
143
Las modificaciones realizadas desde el pizarrón serán reflejadas automáticamente en el editor
de texto.
Las principales clases involucradas en este mecanismo son Link y SharedObject. Un objeto de la clase Link mantiene la referencia deı́tica, mientras que dos objetos de la clase
SharedObject representan una palabra deı́tica y un objeto referenciado.
5.2.6
Mecanismo de proximidad lógica
La proximidad lógica entre dos colaboradores es medida en términos de la relativa cercanı́a
entre los objetos compartidos que están manipulando dichos colaboradores en el espacio de
trabajo compartido de una aplicación colaborativa. Con el fin de facilitar la explicación de este
mecanismo, supongamos que durante una sesión de trabajo, los colaboradores mencionados
están modificando, visualizando y/o anotando objetos compartidos que siguen una estructura
de árbol, e.g., un documento de texto o de imágenes (cf. Figura 5.6), cuyo nodo raı́z es el
nombre del documento (el contenedor de texto e imágenes) o del proyecto (el contenedor de
imágenes) en cuestión.
En la Figura 5.6a, se puede observar que la granularidad de objetos en un documento de
texto va desde el documento completo hasta la palabra. La estructura de dicha figura 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
contener 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 de proyecto hasta nivel de
figuras, las cuales puede ser una lı́nea, un cı́rculo, un rectángulo y un cuadrado. La Figura5.6b
muestra un proyecto de imágenes vectoriales, cuyo nombre es (Pi ), el cual contiene hojas (H)
que sirven de lienzos de dibujo. Dichas hojas contienen imágenes (I) que están compuestas por
figuras (F ) básicas.
Para definir los grados de proximidad lógica en el espacio de trabajo compartido, este mecanismo usa valores de granularidad gruesa con la finalidad de determinar que dichos colaboradores
están:
1. muy cercanos, cuando están accediendo al mismo objeto compartido, sin importar su
respectivo tipo de acceso (e.g., leer, escribir o anotar);
2. más o menos cercanos, cuando están manipulando diferentes objetos compartidos (e.g.,
subsecciones), los cuales tienen el mismo padre (e.g., una sección);
3. 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 ejemplo, consideramos los objetos actuales que dichos colabo-
144
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
radores están accediendo y los objetos potenciales que están al alcance del colaborador un .
Tanto los objetos en curso como los objetos potenciales pueden ser determinados a partir de
las actividades actuales y potenciales de los colaboradores, respectivamente. Ası́, aunque los
colaboradores un y u3 pueden estar distantes uno del otro en el espacio de trabajo compartido,
cuando estén manipulando los objetos o y q respectivamente, la posibilidad de acceder a otros
objetos compartidos (e.g., un puede también manipular q) permite al colaborador un estar potencialmente muy cerca del colaborador u3 en el espacio de trabajo compartido, pero lejos de
los colaboradores u1 y u2 .
Las principales clases involucradas en este mecanismo son AbstractObject, Activity,
Action y SharedObject. Objetos de la clase SharedObject representan los objetos compartidos, los cuales sirven de base para calcular los grados de proximidad lógica. Un objeto
Capı́tulo 5
Proximidad lógica
145
Objeto actual o del componente c de un
Objeto potencial q del
componente d de un
Objeto actual o del compoMuy cerca
nente c de u1
Potencialmente remoto
Objeto actual p del compoMás o menos cerca
nente c de u2 , tal que p 6= o,
Potencialmente remoto
Objeto actual q del compoRemoto
nente d de u3 , tal que d 6= c,
Potencialmente
cerca
muy
Tabla 5.3: Proximidad lógica entre dos colaboradores en un espacio de trabajo compartido
de la clase AbstractObject permite crear la estructura de árbol para los documentos de texto
y de imágenes. Finalmente, objetos de la clase Activity denotan a los objetos potenciales,
mientras que objetos de la clase Action representan al objeto actual. Estas dos últimas clases
están asociadas por supuesto a un objeto de la clase Collaborator.
5.2.7
Mecanismo ubicación fı́sica
Este mecanismo se encarga de determinar si los integrantes de un grupo se encuentran trabajando en el mismo lugar fı́sico y al mismo tiempo (ver Figura 5.7). Los parámetros requeridos
por este mecanismo son: el tiempo y la ubicación de cada colaborador.
• El tiempo es empleado para registrar el momento en que entra y sale cada colaborador
de un lugar especı́fico.
• La ubicación es el lugar fı́sico donde se encuentra el colaborador.
Ambos parámetros se obtienen a través del dispositivo móvil de cada colaborador. Una
opción a utilizar para obtener la ubicación de los colaboradores mediante hardware es usando
la tecnologı́a de comunicación inalámbrica NFC (Near Field Communication)1 . En la entrada
de cada habitación se coloca una etiqueta NFC que representa al lugar fı́sico. Al momento en
que un colaborador llega al lugar y lee, mediante su dispositivo móvil, la etiqueta asociada al
mismo, se registra su presencia en ese lugar y la hora en que ingresó.
Dado que la ubicación de un colaborador se conoce cuando se lee la etiqueta NFC asociada
a la habitación, no es posible realizar el seguimiento de su posición dentro de ese lugar fı́sico.
1
NFC Forum, NFC Forum Technical Specifications, http://www.nfc-forum.org/specs/spec_list/, 2004
146
EntornoComún
Colaborador:
colaborador_a
Colaborador:
colaborador_b
ubica
ción/
horaE
g
reso
Mecanismo:
UbicaciónFísica
Egreso
ra
ión/ho
ubicac
Notificar resultado
a otros componentes
Figura 5.7: Mecanismo de ubicación fı́sica
Por lo tanto, esta información tiene que ser almacenada en una base de datos al momento en
que el colaborador ingrese al lugar.
Dados dos colaboradores identificados como 1 y 2, el mecanismo propuesto comprueba si la
ubicación del colaborador 1 es igual a la ubicación del colaborador 2 y si el tiempo de egreso
de los colaboradores no ha sido registrado. Si ambas condiciones son afirmativas, entonces se
deduce que ambos colaboradores se encuentran co-localizados.
Se decidió emplear la tecnologı́a NFC debido a que está siendo incluida en la mayorı́a de
los dispositivos móviles nuevos, por lo tanto no tenemos que incorporar hardware externo
al dispositivo. Además, se hace uso de etiquetas NFC, las cuales son de bajo costo. Ası́
mismo, se espera que para el año 2014 uno de cada cinco dispositivos móviles cuenten con
dicha tecnologı́a2 . Estas razones hacen que la implementación de este mecanismo sea rentable
y factible.
Se podrı́a utilizar otras tecnologı́as de comunicación para obtener la ubicación fı́sica, e.g.,
sensores infrarrojos o sensores de Identificación por Radio-Frecuencia (RFID). Asimismo, se
podrı́a implementar algún mecanismo por software, e.g., detección de rostros.
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.
El marco propuesto se compone de tres capas: detección, adaptación y espacio de trabajo. La
capa de detección, que se encuentra en la parte inferior del marco, es responsable de reconocer
2
Juniper
Research,
1
in
5
Smartphones
will
http://www.juniperresearch.com/viewpressrelease.php?pr=239, 2004
have
NFC
by
2014,
Capı́tulo 5
147
cambios en las variables contextuales por medio de perceptores lógicos y fı́sicos. La capa de
adaptación está localizada entre las capas superior e inferior del marco XARE.
Esta capa intermedia está a cargo de analizar la información obtenida por la capa de 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 de
adaptación considere que algún tipo de adaptación es necesario, esta capa informa a la capa de
espacio de trabajo cómo debe ser implementada dicha adaptación (cf. Figura 5.8).
Esta última capa mencionada es la capa superior del marco XARE y es responsable de llevar
a cabo las modificaciones solicitadas por la capa de adaptación.
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
La capa de detección se compone de dos tipos de perceptores (cf. Figura 5.8):
1. Perceptores lógicos: son mecanismos de software que pueden identificar cambios en las
siguientes variables contextuales lógicas:
148
• Variable dispositivos: representa las plataformas actuales de interacción de cada
colaborador donde se ejecutan aplicaciones colaborativas. Mediante esta variable es
posible obtener las caracterı́sticas de hardware y software de estos dispositivos para
adaptar las aplicaciones colaborativas al componente conjunto de plataformas del
contexto de uso.
• Variable disponibilidad: denota la disponibilidad de cada colaborador, la cual puede
ser definida manualmente por el propio colaborador o de manera automática al ser
inferida por una aplicación colaborativa (cf. sección 5.2.2). Como se mencionó en
la sección 5.1, esta variable puede tomar los valores presente o ausente, pero si el
colaborador está presente, él puede estar ocupado, accesible o contactable si es posible.
• Variable actividad actual: representa la actividad en curso de cada colaborador, la
cual puede ser inferida automáticamente por una aplicación colaborativa a partir de
las acciones ejecutadas por el colaborador sobre los objetos compartidos.
• Variable proximidad lógica: denota la cercanı́a entre un colaborador y sus colegas en
el espacio de trabajo compartido de una aplicación colaborativa (cf. sección 5.2.6).
2. Perceptores fı́sicos: son principalmente sensores capaces de reconocer cambios en la siguientes variables contextuales fı́sicas:
• Variable configuración de un grupo: por medio de sensores RFID (Radio Frequency
IDentification) y de tecnologı́a Bluetooth, es posible descubrir la entrada y salida
de un colaborador en un lugar especı́fico, con el fin de determinar si un grupo está
colaborando de manera co-localizada o distribuida.
• Variable proximidad fı́sica: denota la cercanı́a entre los dispositivos de un colaborador y los de sus colegas. Por medio de esta variable es posible que dos colaboradores
acoplen sus tablets para crear un espacio de trabajo compartido a partir de dos
espacios privados, como en Connectables [Tandler et al., 2001], o extender un espacio
de trabajo compartido existente.
La capa de adaptación está compuesta de los siguientes módulos (cf. Figura 5.8):
1. Reglas de adaptación: con base en los cambios detectados 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 sea requerida, este módulo también especifica el tipo de técnicas
necesarias para adaptar dicha aplicación, ası́ como las granularidades de adaptación y
recuperación de estado.
2. Medios de adaptación: se refiere a los resultados del proceso de adaptación tales como
son percibidos por los colaboradores en la Interfaz de Usuario (IU). Ası́, el proceso de
adaptación puede utilizar una o varias de las siguientes técnicas:
• Redistribución: consiste en reorganizar los componentes de la IU en diversos dispositivos de interacción. Cuatro tipos de redistribución han sido identificados
Capı́tulo 5
149
[Calvary et al., 2006]: a) de centralizada a centralizada, cuyo objetivo es conservar
el estado centralizado de la IU, e.g., migración de una PC a una PDA; b) de centralizada a distribuida, la cual desmiembra la IU en varias plataformas, e.g., repartición
entre una PC y una PDA; c) de distribuida a centralizada, cuyo efecto es reconcentrar la IU en una sola plataforma; y d) de distribuida a distribuida, la cual modifica
el estado de distribución de la IU.
• Remodelación: involucra la reconfiguración de la IU por medio de inserciones, supresiones, substituciones y reorganización de todos o algunos componentes de la IU.
Las transformaciones aplican a diferentes niveles de abstracción: intra-modal, intermodal y multi-modal. La remodelación intra-modal ocurre cuando los componentes
fuentes son redefinidos dentro de la misma modalidad, e.g., de una interacción gráfica
a otra gráfica. La remodelación inter-modal redefine una modalidad diferente, ya que
los componentes de la IU sujetos a remodelación 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. Finalmente, la remodelación multi-modal permite
la combinación de transformaciones intra- e ı́nter- modales.
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 que la IU completa se ve afectada
por modificaciones; b) espacio de trabajo, el cual se refiere a un espacio que apoya la
ejecución de un conjunto de tareas lógicamente relacionadas, 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 que 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 de recuperación del estado: representa el esfuerzo que los usuarios deben
realizar para continuar con el desarrollo de su actividad, una vez finalizada la adaptación
de la IU. Tres granos de recuperación son considerados [Vanderdonckt, et al., 2008]: a)
nivel de sesión, el cual fuerza al usuario a reiniciar su sesión, perdiendo los efectos de todas
sus acciones ejecutadas; b) nivel de tarea, el cual asegura que todas las tareas terminadas
son validadas de manera persistente, excepto la tarea interrumpida; y c) nivel de acción
fı́sica, la cual asume que el usuario no pierde el efecto de ninguna acción.
La capa de espacio de trabajo está compuesta 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 el estado de una aplicación colaborativa adaptativa. Coutaz y Calvary
identifican tres tipos de meta-interfaz de usuario [Coutaz and Calvary, 2008]: a) metaIU 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 múltiples formas de adaptación, o
150
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: denota el espacio común donde los miembros de un grupo
cooperan por hacer sus contribuciones perceptibles por todos los miembros, cuando la
estratificación no existe, o por algunos miembros de otra manera.
El soporte de almacenamiento del marco XARE está compuesto de dos repositorios (cf.
Figura 5.8):
1. El repositorio de información contextual administra y almacena principalmente 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 necesaria para desplegar las interfaces de
usuario (e.g., diferentes vistas de interactores y espacios de trabajo, frecuencia de uso de
algunos interactores) y la recuperación del estado (e.g., todas las acciones ejecutadas o
tareas terminadas).
5.4
Sı́ntesis
El marco XARE pretende servir como referencia para crear aplicaciones colaborativas adaptativas, dado que pone en evidencia las dependencias que existen entre las clases de dicho marco
y los componentes del contexto de uso. El marco propuesto sirve de base para implementar la
mayorı́a de las aplicaciones identificadas en el capı́tulo 4.
En la tabla 5.4 se hace referencia a los mecanismos que permiten implementar las aplicaciones identificadas en cuatro de los ocho escenarios descritos en el capı́tulo 4. El escenario
“mejoramiento del trabajo colaborativo”, el cual se refiere a asociar objetos de aplicaciones
diferentes, con el fin de mantener en todo momento el contexto de dichos objetos, puede ser
implementado utilizando el mecanismo de “creación de referencias deı́cticas”.
El escenario “remodelación de la interfaz de usuario”, el cual permite la modificación de
componentes mediante ocultación, agregación o sustitución, puede ser implementado mediante
el “mecanismo de ocultar, sustituir y mostrar componentes”. Dicho mecanismo permite adaptar
los componentes dependiendo del rol y del conjunto de dispositivos en uso de cada uno de los
Capı́tulo 5
151
Escenarios
Mecanismos
1. Mejoramiento del trabajo colaborativo
5.2.5. Creación de referencia deı́cticas
2. Remodelación de la interfaz de
usuario
5.2.4. Ocultar, sustituir o mostrar
componentes
3. Redistribución de una aplicación colaborativa
5.2.7. Ubicación fı́sica y
5.2.6. Proximidad lógica
4. Mejoramiento de la conciencia
grupal
5.2.1. Similitud de actividades,
5.2.2. Disponibilidad de un colaborador
5.2.3. Medio de contacto
Tabla 5.4: Sugerencias de mecanismos para implementar las aplicaciones de algunos escenarios
analizados
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 y colaboradores).
El escenario “redistribución de una aplicación colaborativa” 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) “ubicación fı́sica” permite
detectar cuando un grupo está trabajando en un mismo lugar fı́sico o a distancia.
El escenario “mejoramiento del trabajo colaborativo” permite adaptar los medios de contacto y disponibilidad de los colaboradores; este escenario puede llevarse acabo al usar los
siguientes tres mecanismos: 1) “similitud de actividades” permite determinar la similitud de
las actividades de dos colaboradores, 2) “disponibilidad de un colaborador” permite calcular la
disponibilidad del colaborador al usar la similitud 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: “suministro de
información relevante” (cf. sección 4.8) y “Notificaciones multi-modales” (cf. sección 4.9).
152
El escenario “suministro de información relevante”, 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) “similitud de actividades” permite detectar la similitud de actividades entre dos colaboradores, dicho mecanismo permitirá ofrecer
información entre colaboradores dada sus actividades actuales o potenciales.
El escenario “Notificaciones multi-modales” 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) “similitud 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.
Capı́tulo 6
Funcionamiento del marco XARE
El marco XARE está compuesto principalmente por tres capas, las cuales se encargan de
detectar el entorno interno y externo del sistema, de adaptarse a los nuevos cambios e interactuar
con el colaborador. Además dicho marco requiere de dos bases de datos para almacenar diferente
tipo de información relacionada con los colaboradores y el propio sistema.
En la sección 6.1 se muestra las instancias del marco XARE en diferentes dispositivos, ası́
como la manera de comunicarse entre las instancias de dicho marco.
En la sección 6.2 permite conocer la API por cada capa. Finalmente, en la sección 6.3 se
presenta una sı́ntesis de este capı́tulo.
6.1
Instancias del marco XARE
Las capas del marco XARE pueden estar instanciadas en los dispositivos huéspedes, más aún si
estos dispositivos tienen suficientes capacidades, e.g., una computadora portátil, para almacenar
y procesar, pero muchos de los dispositivos no tienen la suficiente capacidad para instanciar
completamente el marco, por lo que estos podrı́an necesitar una entidad externa, e.g., un
servidor. Supongamos una tablet, la cual podrı́a almacenar la capa de espacio de trabajo, pero
un teléfono inteligente no, ası́ que ambos dispositivos podrı́an requerir de una entidad externa
(cf. Figura 6.1).
Para que la entidad externa adapte la interfaz de usuario del dispositivo huésped, éste debe
considerar las caracterı́sticas de hardware y software del dispositivo huésped, las cuales pueden
ser obtenidas de dos maneras:
1. el dispositivo huésped, e.g., un teléfono inteligente, toman la iniciativa de informar a
la entidad externa acerca de sus propias capacidades. Esta solución es adecuada para
153
154
Marco XARE
Espacio Trabajo
Marco XARE
Espacio Trabajo
Adaptación
Mensajes
Detección
Mensajes
Mensajes
Red
Servidor 1
Marco XARE
Servidor N
Marco XARE
Espacio Trabajo
Espacio Trabajo
Adaptación
Adaptación
Detección
Detección
Interfaces
de usuario
Información
contextual
Figura 6.1: Instancias del marco XARE en los dispositivos móviles
soluciones basadas en la Web, donde el dispositivo huésped actúan como cliente y la
entidad externa como servidor;
2. la entidad externa pregunta a los dispositivos huéspedes acerca de sus capacidades.
En el caso de los dispositivos huéspedes con suficientes caracterı́sticas para instanciar completamente el marco XARE, ellos podrán comunicarse con los demás dispositivos mediante
mensajes transmitidos por la red. En cambio, los dispositivos huéspedes que utilizan una entidad externa, ellos se comunicaran con los demás dispositivos por medio de dicha entidad
externa. Las instancias del marco XARE podrán comunicarse con las bases de datos a través
de la red, para obtener u actualizar la información adecuada.
La comunicación entre instancias del marco XARE requiere la API mostrada en la tabla 6.1.
En donde se muestra el envı́o y la recepción de mensajes.
Capı́tulo 6
155
Nombre
Descripción
Errores
Se envı́a un mensaje a los dispositivos contenidos en el arreglo
Boolean Send Messages
(Message, Devices Array)
Clase contenedora:
Comunication
No se encuentra el dispositivo
Salida: Exito o fracaso en
el envı́o del mensaje
Recibe mensaje
Boolean
Receive Message (Message)
Clase contenedora:
Comunication
Mensaje dañado
Salida: Exito o fracaso en
la recepción del mensaje
Tabla 6.1: API de la comunicación entre instancias del marco XARE
6.2
API de comunicación entre las capas
Como se dijo en la sección 5.3 del capı́tulo 5, el marco XARE esta compuesto por las siguientes
capas: espacio de trabajo, detección y adaptación.
API de la capa de espacio de trabajo
Esta capa es responsable de llevar a cabo la adaptación acordada por la capa adaptación. En
la tabla 6.2
Nombre
Descripción
Errores
Actualiza la sesión al registrar su
inicio de sesión un colaborador
Void
Update Session
(ID Collaborator,
ID Session)
Clase contenedora:
GroupOfCollaborators
Salida: No aplica
Continúa en la página siguiente
No se encuentra la
sesión
156
Nombre
Descripción
Errores
Muestra la disponibilidad del
colaborador observado
Void
play Availability
servedUser)
Dis(Ob-
No se encuentra el colaborador observado
Clase contenedora:
UserInterface
Salida: No aplica
Muestra los medios de contacto
disponibles que puede tener el
colaborador observador
Void
Display ContactMeans (ObserverUser)
Clase contenedora:
Interface
User-
No se encuentra el colaborador observado
Salida: No aplica
Void
Display MetaIU
(Array, ID Device)
Muestra una meta interfaz de
usuario con las opciones incluidas
en un arreglo sobre el dispositivo
indicado
Clase contenedora:
Interface
User-
Problemas
conexión
con
dispositivo
de
el
Problemas
conexión
con
dispositivo
de
el
Salida: No aplica
Actualiza el desktop de un colaborador en un dispositivo
Void
Display Desktop
(ID Collaborator,
ID Device)
Clase contenedora:
Interface
User-
Salida: No aplica
Tabla 6.2: API de la capa de espacio de trabajo
API de la capa de adaptación
Esta capa 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
Capı́tulo 6
157
privados de una aplicación colaborativa. Cuando la capa adaptación considere que la adaptación
al cambio contextual es necesaria, esta capa informa a la capa espacio de trabajo cómo debe ser
implementada dicha adaptación.
La API de la capa de adaptación se muestra en la tabla 6.3
Nombre
Descripción
String
Create Deixis
(Deictic Word,
ID Document, ID SharedObject)
Errores
Crear una referencia deı́ctica de
una imagen o un texto
No se encuentra el objeto
Clase contenedora: Link
Salida: Referencia Deı́ctica
Despliega el objeto que está
ligado a dicha deixis
Void
Show Deixis
(ID Deixis)
No se encuentra la referencia deı́ctica
Salida: No aplican
Image
ate ImageCopy
(ID Deixis)
Cre-
En el pizarrón multiusuario se
crea una copia (ID ImgCopy) de
la imagen referenciada
No se encuentra la referencia deı́ctica
Salida: Genera una copia
A un grupo que lleva una conversación se le sugiere ver la
conversación de otro grupo
Boolean Follow Conversation (ID SuggestConver,
ID CurrentConver)
Clase contenedora:
munication
Com-
Salida:
Verdadero o falso
dependiendo si el colaborador
sigue o no una conversación
No se encuentra las
conversaciones
158
Nombre
Descripción
Errores
La copia de la imagen referenciada es actualizada en su
documento fuente
Image
Update ImgRef
(ID ImgCopy)
Clase contenedora: Image
Salida:
fuente
Actualiza la imagen
No se encuentra la
copia de la imagen, o
existen problemas de
escritura en el documento fuente
Adapta el desktop del colaborador considerando el rol y los
dispositivos en uso
Boolean Adapt DesktopCollaborator
(Array Collaborator,
ArrayDevice, ID Collaborator)
Clase contenedora: RichDesktop
No se encuentra el colaborador
Salida:
Devuelve verdadero
en caso de adaptar la interfez de
usuario, en otro caso regresa falso
Void
Update Knowledge Tools
(Array CollectedGroup,
Array DistributedGroup,
Array Asent Group)
La barra de conciencia es actualizada cada vez que se detecta un
cambio en la configuración del
grupo
Col-
Clase contenedora:
laboratorBar
No se encuentra la
barra
Salida: No aplica
Calcula la disponibilidad
colaborador observado
String
Calculate Availability
(ObservedUser, ObserverUser,
Observer Activities)
Clase contenedora:
ability
Salida:
bilidad
del
Avail-
El tipo de disponi-
No se encuentra el colaborador observado o
el observador
Capı́tulo 6
159
Nombre
Descripción
Errores
Calcula la similitud de las actividades de dos colaboradores
String
Calculate SimilarityActivities
(ObservedUser,
ObserverUser)
Clase contenedora:
ity
Salida:
tud
String
CalculateContactMeans
(ObservedUser, ObserverUser,
ObservedUser Disponibility, ObservedUser Device,
ObserverUser Device)
Activ-
el observador
El grado de simili-
Obtiene los medios de contacto
disponibles entre dos colaboradores
Clase contenedora:
tactMeans
Con-
el observador
Salida:
Los dispositivos
disponibles para la conversación
Tabla 6.3: API de la capa de adaptación
Capa de detección Esta capa se encarga de detectar de manera automática algún cambio
ocurrido en el contexto, i.e., los eventos relevantes tanto externos como internos en la aplicación.
La API de la capa de detección se muestra en la tabla 6.4.
Nombre
Descripción
Errores
Actualiza las caracterı́stica del
dispositivo
Boolena
date DeviceList
ID Device)
Up(Array,
Clase contenedora:
ware
Hard-
Salida:
Verdadero en caso
de encontrar el dispositivo; falso
en caso contrario
160
Nombre
Descripción
Errores
Actualiza el perfil y preferencias
del colaborador
Boolean
Update Collaborator
(Array, ID Collaborator)
Clase contenedora:
laborator
Col-
Salida:
Verdadero cuando
encuentra el colaborador, falso
de otro modo
Actualiza la ubicación fı́sica de
un colaborador, ası́ como su
tiempo de ingreso
Boolean
Update Collaborator
(Time,
ID Room,
ID Collaborator)
Clase contenedora:
laborator
Col-
No se encuentra el
ID Colaborador
Salida:
Verdadero cuando
de otro modo
Establece el dispositivo que está
usando un colaborador
Boolean
Link Device
(ID Device,
ID Collaborator)
Clase contenedora:
ware
Hard-
Salida:
Verdadero cuando
de otro modo
Regresa el perfil y rol del colaborador
String Get Collaborator
(ID Collaborator)
Clase contenedora:
laborator
Col-
Salida:
Un arreglo con la
información mencionada
Capı́tulo 6
161
Nombre
Descripción
Errores
Regresa las caracterı́sticas de un
dispositivo en especı́fico
String
Get CharacteristicsDevice (ID Device)
Clase contenedora:
ware
Hard-
Salida:
Un arreglo con la
información mencionada
Agrega un miembro a un grupo
co-localizado o distribuido
Boolean
Update ConfigurationGroup (ID Collaborator,
ID Group)
Clase contenedora: GroupOfCollaborators
No se encuentra el
grupo
Salida:
Verdadero en caso
de encontrar el grupo; falso en
caso contrario
Guarda las configuraciones de un
grupo
Boolean
Save ConfigSession
(Array Collaborator,
ray)
Ar-
Clase contenedora: GroupOfCollaborators
No se pudo guardar la
configuración
Salida:
Verdadero cuando
no ocurrio ningún error, de otro
modo falso
Regresa la actividad actual del
colaborador ası́ como la fecha
lı́mite de esta
String
Get Currently Activities Clase contenedora:
(ID Collaborator)
ity
Salida:
Actividad
y fecha lı́mite
Activ-
actual
Tabla 6.4: API de la capa de detección
162
6.3
Sı́ntesis
Las APIs necesarias para el funcionamiento de cada capa del marco fueron mostradas en este
capı́tulo, de tal forma que se indica el tipo de valor que regresa dicha API ası́ como los tipos
de valores que recibe. Se incluyó también algunos errores que deben ser considerados.
Estas APIs involucran varias partes de un sistema, i.e., dsde el despliegue de las interfaces
de usuario hasta la detección de eventos fı́sicos y virtuales.
En este capı́tulo se se muestra como podrı́a ser instanciado el marco en los diferentes dispositos de cómputo, ya que estos están cambiando constantemente en caracterı́sticas de hardware
y software.
Capı́tulo 7
Conclusiones y trabajo a futuro
Como preámbulo a emitir en las conclusiones de este trabajo, es muy importante recordar que
el contexto de este estudio no está reducido a un campo limitado de aplicaciones particulares,
sino al ambiente de hoy en dı́a en el que todos los usuarios están progresivamente entrando de
manera insoslayable: el usuario utiliza cada vez más los dispositivos fijos y móviles del ambiente
donde está interactuando con otros usuarios móviles mediante aplicaciones interactivas que
ofrecen interfaces sofisticadas de trabajo colaborativo multimedia incluso multimodal. Ası́, las
interfaces de colaboración son complejas, pero las caracterı́sticas de los potenciales dispositivos
de interacción son muy diversas. Además, el usuario es más exigente y ahora quiere no solamente
poder pasar de un dispositivo a otro, sino usar de manera simultanea diversos dispositivos
combinándolos para definir un ambiente de interacción sofisticado y eventualmente más natural
para colaborar de manera local y/o remota con otros usuarios.
En el marco de tal ambiente, este tema de investigación se centra en proveer una definición de
contexto de uso para los sistemas colaborativos, la cual sirvió para crear un marco de desarrollo
de aplicaciones colaborativas adaptables al contexto que considera tanto la interfaz de usuario
como el trabajo generado por cada colaborador.
El área del trabajo colaborativo se ve enriquecido con este trabajo de investigación porque
define el contexto de uso de los sistemas colaborativos, el cual está basado en el contexto de
uso de los sistemas mono-usuario.
En este trabajo de investigación el contexto de uso de los sistemas colaborativos es ejemplificado por varios escenarios. Algunos de estos fueron implementados en aplicaciones colaborativas. A partir de estos escenarios se propone un marco de desarrollo ası́ como un conjunto de
APIs que permiten a los desarrolladores de software diseñar aplicaciones colaborativas capaces
de adaptarse al contexto en el cual se están ejecutando.
Enseguida presentamos más a detalle las conclusiones resultantes hasta el momento, ası́ como
los temas a investigar y desarrollar más adelante para obtener resultados más completos.
163
164
7.1
Conclusiones
En este trabajo introducimos la subárea del campo de Interacción Humano-Computadora (IHM)
llamada “Plasticidad de las Interfaces de Usuario”; con la finalidad de evolucionar las interacciones de los usuarios, que antes trabajaban individualmente, hacia el trabajo colaborativo
usando dispositivos heterogéneos, debido a que la importancia de dicha subárea, Trabajo Colaborativo, parece cada vez más importante. El desarrollo del presente trabajo de investigación
se centra en considerar varios puntos relevantes de este entorno de colaboración creciente, para
definir una interfaz de usuario plástica en la etapa de diseño y/o en tiempo de ejecución.
También, los sistemas plásticos deben informar al usuario final acerca de las caracterı́sticas de
la nueva adaptación, ya sea que el usuario intervenga en el proceso de adaptación o solo sea un
observador pasivo.
Varias de las aplicaciones que presentamos como ejemplos en este trabajo permiten expresar
de manera visual la plasticidad, e.g., cambiar de modalidad gráfica a textual cuando el dispositivo no soporta la modalidad gráfica tal como la aplicación lo requiere; redistribuir la interfaz
de usuario entre dispositivos heterogéneos (e.g., pizarrones electrónicos, PDA, PC y mesas) y/o
adaptarse a la tarea de un colaborador particular.
A partir de estos ejemplos, podemos observar que la mayorı́a de los sistemas se focalizan en la
plataforma (dispositivo, sistema operativo, sistema de interacción y herramientas de software).
Principalmente, estos sistemas se ejecutan sobre PDAs, tablets PC y/o computadoras portátiles;
en cambio, el uso de dispositivos como pizarrones electrónicos, teléfonos inteligentes o relojes
constituyen plataformas no tan usadas frecuentemente. Muy pocos de los sistemas existentes
consideran al usuario, ası́ la tendencia respecto al usuario se limita a: i) considerar sus tareas
(frecuencia y preferencia) o ii) determinar si un usuario está usando dos o más dispositivos.
Los marcos conceptuales o de desarrollo que son analizados en este trabajo de investigación
fueron seleccionados debido a que implementan algunas de las caracterı́sticas de las interfaces
de usuario plásticas multimodales.
A partir del análisis de estos marcos con respecto al contexto de uso se puede observar que
existe una tendencia a tomar en cuenta varias peculiaridades del usuario, e.g., su perfil, sus
tareas asignadas y su rol, con la finalidad de proveer una mejor adaptación. Las caracterı́sticas
anteriores contemplan ciertas acciones en especı́fico, e.g., detectar 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 de manera dinámica clusters
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 dependiendo de su ubicación.
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
Capı́tulo 7
165
una meta-interfaz de usuario, ası́ como realizar la adaptación de la aplicación en tiempo de
ejecución, dejando de lado los demás puntos a considerar.
Un marco organizacional de clases y mecanismos
En este trabajo de tesis proponemos un marco organizacional de clases (diagrama de clases)
cuyo objetivo es constituir una referencia para diseñar aplicaciones plásticas colaborativas,
ya que se pueden observar las dependencias que existen entre las clases y las dimensiones del
contexto de uso. Dicho diagrama fue definido considerando los escenarios propuestos, los cuales
fueron analizados como pre-requisito a este trabajo de investigación.
En particular, en este trabajo proveemos una sı́ntesis de los mecanismos que permiten implementar cuatro de los siete escenarios descritos en esta tesis. El escenario que considera los
objetos compartidos, el cual se refiere a crear ligas entre una palabra clave de la mensajerı́a
instantánea y un objeto compartido del editor colaborativo mediante la función Deixis, puede
ser implementado mediante el mecanismo para la “creación de referencias deı́cticas”. Este
mecanismo podrı́a permitir crear ligas no solo desde la aplicación de mensajerı́a instantánea
sino desde cualquier otra aplicación.
En el caso especı́fico del escenario que soporta la modificación de componentes mediante la
ocultación, agregación y/o sustitución de un componente de la interfaz de usuario, este se puede
implementar usando mecanismos dedicados que permitan adaptar los componentes dependiendo
de los roles del colaborador y del conjunto de dispositivos en uso. Estos mecanismos pueden
usarse para ocultar los ı́conos no relacionados con el rol del usuario (sus actividades), cuando
la pantalla del dispoposiblessitivo 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 interfaz
de usuario en el caso de que el dispositivo soporte dicho cálculo o usar un servidor para que
este les proporcione la interfaz de usuario considerando las caracterı́sticas del contexto actual
(dispositivos y colaboradores).
El escenario que presenta la adaptación de componentes en interacciones co-localizadas, distribuidas o hı́bridas puede llevarse acabo utilizando los dos mecanismos siguientes: 1) el mecanismo de “detección de proximidad lógica” que permite identificar si el grupo de colaboradores
se encuentra trabajando en la proximidad de puntos de intereses comunes, mientras que 2) el
mecanismo de “detección de proximidad fı́sica” permite determinar si el grupo de usuarios está
trabajando en un mismo lugar o a distancia.
El escenario que introduce la adaptación de los medios de contacto y disponibilidad de los
colaboradores puede llevarse acabo al usar los siguientes tres mecanismos que permiten: 1)
determinar “la similitud de las actividades” de dos colaboradores, 2) calcular “la disponibilidad”
de los colaboradores tomando en cuenta la similaridad de las actividades del usuario a contactar
y del que desea establecer el contacto, y 3) definir “los medios de contacto” considerando la
disponibilidad y los dispositivos de interacción de los colaboradores.
De igual manera, se introdujo un escenario que presenta el principio de la adaptación de
la información, cuyo objetivo es proveer información dado un contexto determinado. Este
166
escenario puede ser implementado casi por completo al usar los siguientes mecanismos: 1)
el mecanismo de “ocultación, sustitución y despliegue” de componentes que se puede usar
para proveer información necesaria en función del rol del colaborador y del dispositivo en uso,
2) el mecanismo de “ubicación fı́sica” que nos permitirá saber el momento en que entra un
colaborador a un lugar especı́fico y ası́ proveer la información adecuada dados sus roles y sus
actividades, y 3) el mecanismo de “similitud de actividades” que permite detectar la similitud
de actividades entre dos colaboradores.
Finalmente, un escenario especı́fico ilustra el uso de diferentes modalidades, cuyo objetivo
es la notificación de información usando diferentes modalidades de eventos relacionados con la
ubicación de un colaborador, la actualización de información relevante para los colaboradores,
ası́ como la actividad que está llevando en cierto momento. Este escenario se puede implementar
parcialmente al usar los siguientes dos mecanismos: 1) el mecanismo de “ubicación fı́sica” para
conocer en donde se encuentra un colaborador y ası́ determinar si está solo o acompañado, y
2) el mecanismo de “similitud de actividades” para determinar si la actividad del colaborador
está relacionada con la actividad de quien potencialmente recibirá la notificación.
En especı́fico estudiamos en profundidad los escenarios que tienen implementadas sus aplicaciones. Algunas de las aplicaciones desarrolladas (e.g., la herramienta de votación y el editor
de mapas mentales) combinan algunos aspectos propuestos en los escenarios mencionados, lo
cual permitió generalizar la adaptación de dichas aplicaciones al rol, al dispositivo y a la configuración del grupo. A partir de la herramienta de desktop enriquecido se pudo generalizar
la manera de referenciar objetos compartidos entre dos aplicaciones, ası́ como de detectar
cuando se hace referencia de manera directa o indirecta a un mismo objeto compartido. Con
la aplicación de disponibilidad y medios de contacto se generalizó la manera de calcular la
disponibilidad de los colaboradores y sus medios de comunicación más adecuada. En cambio,
el administrador de contenidos NFC no se pudo generalizar dicho proceso, pero si nos permitió
destacar algunas de las variables contextuales a considerar.
Las cinco aplicaciones presentadas en esta sección han sido implementadas para soportar
el trabajo colaborativo, algunas de ellas permiten tanto el trabajo co-localizado como el distribuido, pero otras solo una de esas dos opciones.
Las herramientas que permiten tanto el trabajo co-localizado como el trabajo distribuido
corresponden a: herramienta de votación y editor de mapas mentales. Ambas aplicaciones
comparten una barra de colaboradores. Dicha barra se adapta dependiendo del modo de trabajo.
Las herramientas que solo soportan el trabajo distribuido corresponden al desktop enriquecido
y a la herramienta de disponibilidad y medios de contacto. La herramienta desktop enriquecido
permite ejecutar tres aplicaciones y crear ligas entre objetos compartidos. La herramienta
de disponibilidad y medios de contacto permite 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.
Capı́tulo 7
167
El 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.
XARE - un marco de desarrollo
La aportación principal de este trabajo de investigación consiste en proponer un marco de
desarrollo denominado XARE para orientar y ofrecer mecanismos básicos a los desarrolladores
y ası́ ayudarlos a definir aplicaciones adaptativas al contexto considerando cinco de las siete
dimensiones de la plasticidad orientada a los sistemas mono-usuario. Las cinco dimensiones
consideradas en el marco corresponden a: 1) contexto de uso, 2) meta-interfaz de usuario con
o sin negociación, 3) medios de adaptación (remodelación y redistribución), 4) granularidad
de adaptación y 5) granularidad de recuperación del estado. La dimensión contexto de uso
es la más estudiada en este tema de investigación, ya que ha sido definida para los sistemas
colaborativos y ha sido abordada en todos los escenarios presentados, e.g., adaptación de la
aplicación al rol y perfil del colaborador (grupo de colaboradores), a los dispositivos (conjunto
de plataforma) y a los objetos compartidos en uso (entorno compartido).
Algunos componentes del contexto de uso están relacionados al 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 del colaborador (plataforma, disponibilidad, actividad y el tiempo final de
la actividad actual) ası́ como de los colegas que desean contactar. Como lo vimos, examinando el escenario ilustrado, el mecanismo de “disponibilidad de un colaborador”, el estado de
disponibilidad de un colaborador depende de la similitud entre su actividad y la de sus colegas.
Las dimensiones de plasticidad de una aplicación colaborativa se caracterizan determinando
i) si la aplicación necesita la adaptación de una única entidad o de diversas entidades, ii) qué
tipo(s) de variable(s) contextual(es) es(son) considerada(s) para la adaptación y iii) qué tipo
de adaptación (presentación, ejecución y aumentación) es requerido. A partir del análisis del
diagrama de clases del marco XARE, se puede observar que solamente una mı́nima parte de
este diagrama considera la dimensión “entidad única”, especialmente para la asignación de
roles o la disponibilidad del colaborador, ya que se considera a cada colaborador por separado.
En cambio, la mayor 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 por uno o
varios colaboradores y la interfaz de usuario de cada colaborador se puede ver restringida por la
plataforma de los colaboradores y las 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 colaborativos adaptativos son varias, e.g., para establecer el medio de contacto se requiere conocer la plataforma,
la actividad, la disponibilidad de un colaborador y la fecha actual, la cual permite saber qué
tan cercana es la fecha lı́mite de la actividad en curso. Por otra parte, las acciones de los
colaboradores pueden ser explotadas con el fin de que la aplicación detecte cuando dos o más
colaboradores están haciendo referencia sobre un mismo objeto compartido.
168
Las variables contextuales son igualmente muy útiles y comúnmente usadas cuando se requiere tener un conocimiento actualizado del rol del colaborador para actualizar su ambiente
de trabajo, e.g., para mostrar solamente las funciones que le están permitidas. 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) introducida en el
presente trabajo 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 comunicaciones con un colaborador: en este caso, el sistema solo presenta
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 más colaboradores están haciendo referencia a un objeto compartido, e.g., un colaborador
describe un diagrama, mientras otro modifica el mismo diagrama. Otro caso en que se usa la
información aumentada es cuando dos o más colaboradores hacen una referencia deı́ctica a 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
Algunos de los puntos más relevantes a considerar en los desarrollos futuros de este trabajo de
investigación son los siguientes: i) automatizar algunos escenarios, ii) poner el marco XARE a
disposición de desarrolladores para que sea evaluado, iii) depurar las librerı́as que implementan
el marco, iv) ofrecer una aplicación para un sector de aplicación especı́fico y evaluarla, ası́
como v) abordar las demás dimensiones propuestas en el ámbito de las interfaces de usuario
plásticas mono-usuario y vi) eventualmente proponer su adaptación en un ambiente de trabajo
colaborativo.
La automatización de los escenarios que han quedado pendientes permitirá enriquecer el
marco de desarrollo propuesto mediante clases y mecanismos. Los escenarios pendientes se
enlistan a continuación:
• Identificar al menos una aplicación del escenario que permite ocultar la información,
e.g., imágenes y texto, para que los colaboradores no se preocupen por la información
desplegada en sus pantallas ante la presencia de personas no autorizadas.
• Automatizar el escenario que permite usar diferentes modalidades para notificar eventos
internos y externos al sistema. El objetivo de este escenario es proveer una adecuada
notificación de eventos que involucren diferentes modalidades considerando la actividad
actual del receptor, ası́ como su ubicación y la relevancia de dicha notificación.
Capı́tulo 7
169
• Automatizar aún más el escenario que provee información con la finalidad de enriquecer
la colaboración, mediante información necesaria para un mejor desempeño de los colaboradores.
Otro punto muy importante que queda pendiente es ofrecer el marco de desarrollo XARE a
desarrolladores de software para que ellos evalúen la utilidad de dicho marco.
El trabajo a futuro que se refiere a depurar las librerı́as que implementan el marco de desarrollo tiene como finalidad poner dichas librerı́as a disposición de cualquier desarrollador que
desee crear colaborativas conscientes de contexto.
El punto que se focaliza a ofrecer una aplicación a un sector especı́fico, e.g., el área médica,
tiene como objetivo incorporar la mayorı́a de las adaptaciones que ofrece el marco XARE en
una sola aplicación. El objetivo es ofrecer una aplicación para que los trabajadores de dicho
sector evalúen la utilidad de las adaptaciones que esta ofrece.
En este tema de investigación se abordaron cinco de las siete dimensiones identificadas en el
diseño y la implementación de las interfaces de usuario plásticas orientadas a los sistemas monousuario. Ası́ la consideración del espacio tecnológico y del despliegue de la interfaz de usuario
constituye el último punto a considerar en el trabajo a futuro de este trabajo de investigación.
170
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.
[Buvaĉ et al., 1995] Buvaĉ, S., Buvaĉ, V. and Mason, I.A., Metamathematics of contexts, Fundamenta Informaticae, 23 (3), pp. 412–419, 1995.
[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, 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

Cómo dirigir con integridad en nuestro lugar de

universidad de castilla-la mancha escuela superior

Mapeo facial de emociones sintéticas - UPM ASLab

Desarrollamos nuestro Talento