XARE: Marco de desarrollo para sistemas colaborativos ... · de dispositivos fijos y móviles (e.g., pizarrones electrónicos, tabletas digitales, PDAs y smart-phones) impone nuevos

CENTRO DE INVESTIGACION Y DE ESTUDIOS

AVANZADOS DEL INSTITUTO POLITECNICO

NACIONAL

UNIDAD ZACATENCO

DEPARTAMENTO DE COMPUTACION

XARE: Marco de desarrollo para sistemas colaborativos conscientes

de contexto

Tesis que presenta

Gabriela Sanchez Morales

para obtener el Grado de

Doctora en Ciencias

en Computacion

Codirectores de la Tesis

Dra. Sonia Guadalupe Mendoza Chapa

Dr. Dominique Decouchant

Mexico, D.F. Diciembre 2013

ii

iii

Resumen

Actualmente, la mayorıa de las aplicaciones suponen que la interaccion hombre-maquina estaconfinada en un solo dispositivo de computo (e.g., una PC) donde el usuario emplea disposi-tivos de entrada/salida tradicionales (e.g., monitor, teclado y raton). Sin embargo, la crecienteproliferacion de dispositivos de computo y el progreso de las redes de comunicacion potencial-mente transforman al usuario en un ente que se desenvuelve en un ambiente variable y queutiliza dispositivos de computo diversos, con el fin de satisfacer sus necesidades. Esta variedadde dispositivos fijos y moviles (e.g., pizarrones electronicos, tabletas digitales, PDAs y smart-phones) impone nuevos requerimientos a las aplicaciones, como la capacidad de adaptarse acambios en el contexto de uso, definido en terminos del usuario, de la plataforma y del en-torno. Sin embargo, el desarrollo por separado de diferentes versiones de una misma aplicacionno solo es extremadamente costoso en terminos de desarrollo y mantenimiento, sino tambienpuede dar lugar a comportamientos ergonomicos inconsistentes. La plasticidad de sistemasinteractivos es una lınea de investigacion que pretende ofrecer soluciones a estos problemas.Esta lınea de investigacion esta inspirada en la propiedad de los materiales que les permiteexpandirse y contraerse bajo restricciones naturales, sin romperse. Aplicada a sistemas inter-activos, la plasticidad se refiere a la capacidad de adaptarse a cambios en el contexto de uso,preservando un conjunto de criterios (e.g., usabilidad y continuidad). En el dominio de lossistemas mono-usuario, la plasticidad ha sido estudiada principalmente mediante la definicionde algunos conceptos y el desarrollo de algunos prototipos de laboratorio. Por el contrario,en el dominio de los sistemas colaborativos el estudio de interfaces plasticas practicamente noha sido explorado a pesar de la necesidad inminente de dotar a las interfaces multi-usuariode la propiedad de adaptacion a cambios contextuales. En los sistemas colaborativos, la ad-ministracion del espacio de despliegue es una actividad particularmente crıtica, debido a queuna interfaz multi-usuario provee componentes graficos para hacer uso de las funciones de laaplicacion, sino tambien ofrece componentes graficos adicionales para remplazar la informacion(coordinacion y comunicacion) que se pierde cuando los colaboradores no interactuan cara acara. Este proyecto de investigacion pretende ofrecer soluciones tanto teoricas como practicasque faciliten el desarrollo de sistemas cooperativos plasticos.

iv

Indice general

Indice de figuras ix

Indice de tablas xiii

1 Introduccion 1

1.1 Trabajo Cooperativo Asistido por Computadora . . . . . . . . . . . . . . . . . . 1

1.2 Interaccion Humano-Computadora . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3 Contexto de investigacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.4 Planteamiento del problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.5 Objetivos del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.6 Organizacion del documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2 Interfaces de usuario plasticas en sistemas interactivos 13

2.1 Problemas encontrados en las interfaces de usuario plasticas multi-modales . . . 13

2.2 Percutores de plasticidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.2.1 Remodelacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.2.2 Redistribucion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.2.3 Migracion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.3 Granularidad de adaptacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.4 Granularidad de recuperacion del estado . . . . . . . . . . . . . . . . . . . . . . 29

2.5 Despliegue de la interfaz de usuario . . . . . . . . . . . . . . . . . . . . . . . . . 30

v

vi INDICE GENERAL

2.6 Cobertura del contexto de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.7 Cobertura de espacio tecnologico . . . . . . . . . . . . . . . . . . . . . . . . . . 36

2.8 Meta-interfaz de usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

2.9 Otras dimensiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

2.9.1 Tipo de adaptacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

2.9.2 Sistemas mono-entidad o multi-entidad . . . . . . . . . . . . . . . . . . . 39

2.9.3 Variables contextuales . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

2.10 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3 Marcos de desarrollo de sistemas plasticos 43

3.1 Marco de Referencia Unificado para Interfaces de Usuario Multi-Objetivo . . . . 44

3.1.1 Modelos ontologicos, arquetıpicos y observadores . . . . . . . . . . . . . . 44

3.1.2 Implementacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

3.2 CAMELEON-RT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

3.2.1 Capas de sistemas interactivos, DMP y plataforma . . . . . . . . . . . . 49

3.2.2 Implementacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

3.3 Marco de Plasticidad Implıcita . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

3.4 Marco de Plasticidad Explicita Colaborativa . . . . . . . . . . . . . . . . . . . . 53

3.4.1 Fases ARP, CRP, IMP y PIM . . . . . . . . . . . . . . . . . . . . . . . . 54

3.4.2 Implementacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

3.5 Marco para la Adaptacion de la Conciencia de Contexto en Despliegues Publicos 56

3.6 Marco y Arquitectura para Recomendaciones de Conciencia de Contexto Grupal 59

3.7 Marco Generico de Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

3.7.1 Capas de conocimiento, estado, contextualizacion y adaptacion . . . . . . 61

3.7.2 Implementacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

3.8 Analisis comparativo de los marcos analizados . . . . . . . . . . . . . . . . . . . 65

3.9 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

INDICE GENERAL vii

4 Analisis de requerimientos del marco XARE 73

4.1 Contexto de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

4.1.1 Recapitulacion del contexto de uso de los sistemas mono-usuario . . . . . 74

4.1.2 Contexto de uso de los sistemas cooperativos . . . . . . . . . . . . . . . . 75

4.2 Relacion entre escenarios y aplicaciones . . . . . . . . . . . . . . . . . . . . . . . 76

4.3 Escenario 1: Mejoramiento del trabajo colaborativo . . . . . . . . . . . . . . . . 79

4.3.1 Preambulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

4.3.2 Descripcion del escenario . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

4.3.3 Desktop enriquecido . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

4.4 Escenario 2: Remodelacion de componentes de la interfaz de usuario . . . . . . . 89

4.4.1 Preambulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

4.4.2 Descripcion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

4.4.3 Editor de mapas mentales . . . . . . . . . . . . . . . . . . . . . . . . . . 92

4.5 Escenario 3: Redistribucion del sistema colaborativo en funcion de la configu-racion del grupo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

4.5.1 Preambulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

4.5.2 Planteamiento del escenario 3 . . . . . . . . . . . . . . . . . . . . . . . . 99

4.6 Escenario 4: Adaptar los medios de contacto y de disponibilidad . . . . . . . . . 101

4.6.1 Preambulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

4.6.2 Planteamiento del escenario . . . . . . . . . . . . . . . . . . . . . . . . . 101

4.6.3 Herramienta disponibilidad y medios de contacto . . . . . . . . . . . . . 105

4.7 Escenario 5: Ocultar informacion . . . . . . . . . . . . . . . . . . . . . . . . . . 108

4.7.1 Preambulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109


4.8 Escenario 6: Adaptar la informacion . . . . . . . . . . . . . . . . . . . . . . . . 110

4.8.1 Preambulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110


4.8.3 Herramienta administrador de contenidos vıa NFC . . . . . . . . . . . . 114

viii INDICE GENERAL

4.9 Escenario 7: Uso de diferentes modalidades en la notificacion . . . . . . . . . . . 118

4.9.1 Preambulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118


4.10 Aplicaciones de prueba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

4.10.1 Herramienta de votacion . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

4.11 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

5 Diseno del marco XARE 129

5.1 Diagramas de clases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

5.1.1 Diagrama de clase del contexto de uso de los sistemas cooperativos . . . 130

5.1.2 Diagrama de clases del vigilante . . . . . . . . . . . . . . . . . . . . . . . 134

5.2 Mecanismos del marco XARE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

5.2.1 Mecanismo de similaridad de actividades . . . . . . . . . . . . . . . . . . 137

5.2.2 Mecanismo de disponibilidad de un colaborador . . . . . . . . . . . . . . 139

5.2.3 Mecanismo de medios de contacto . . . . . . . . . . . . . . . . . . . . . . 142

5.2.4 Mecanismo de ocultar, sustituir y mostrar componentes . . . . . . . . . . 143

5.2.5 Mecanismo de creacion de hiperligas entre los objetos compartidos . . . . 144

5.2.6 Mecanismo de proximidad logica . . . . . . . . . . . . . . . . . . . . . . 146

5.2.7 Mecanismo tipo de trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . 148

5.3 Marco XARE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150

5.3.1 Capas del marco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150

5.4 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

6 Validacion del marco Xare 157

6.1 API del marco Xare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

6.2 Medio de contacto y disponibilidad” . . . . . . . . . . . . . . . . . . . . . . . . 158

6.2.1 Dimensiones abordadas en esta propuesta . . . . . . . . . . . . . . . . . 158

6.2.2 Relacion entre la propuesta y el marco de adaptabilidad plastica . . . . . 161

INDICE GENERAL ix

6.3 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

7 Conclusiones y trabajo a futuro 167

7.1 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

7.2 Trabajo a futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

A Publicaciones 171

Referencias 173

x INDICE GENERAL

Indice de figuras

1.1 Vision general de la interaccion multimodal mediante un enfoque centrado en elusuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.2 Contexto de investigacion de este proyecto doctoral . . . . . . . . . . . . . . . . 7

1.3 Organizacion del documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.1 Espacio del problema de las interfaces de usuario plasticas multimodales . . . . 15

2.2 Remodelacion en el sistema de control de calefaccion . . . . . . . . . . . . . . . 18

2.3 Todos los niveles de redistribucion en el sitio Web de Sedan-Bouillon . . . . . . 20

2.4 Niveles de redistribucion de Roomware: de centralizada a centralizada (desde “c”hacia “a”), de centralizada a distribuida (desde “a” hacia “b”) y de distribuidaa centralizada (desde “b” hacia “c”) . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.5 Niveles de redistribucion de CamNote: de centralizada (en una PC) a distribuida(entre una PC y una pocket PC) y viceversa . . . . . . . . . . . . . . . . . . . . 22

2.6 Niveles de redistribucion de ConnecTables: de centralizada a distribuida y viceversa 22

2.7 Niveles de redistribucion de MindMap: de centralizada a distribuida y viceversa 23

2.8 Grano de adaptacion en otros sistemas interactivos . . . . . . . . . . . . . . . . 24

2.9 Grano de adaptacion a nivel de tarea en FlexClock . . . . . . . . . . . . . . . . 25

2.10 Granos de adaptacion a nivel total y de interactor en el sistema de control decalefaccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.11 Grano de adaptacion a nivel de espacio de trabajo en el sitio Web de Sedan-Bouillon 27

2.12 Grano de adaptacion a nivel de espacio de trabajo en el sistema Ubidraw . . . . 27

2.13 Grano de adaptacion a nivel de espacio de trabajo en el sistema CamNote . . . 28

2.14 Grano de adaptacion a nivel de pıxel en el sistema Roomware . . . . . . . . . . 28

xi

xii INDICE DE FIGURAS

2.15 Grano de adaptacion a nivel de pıxel en el sistema ConnecTables . . . . . . . . . 29

2.16 Grano de adaptacion a nivel de pıxel en el sistema MindMap . . . . . . . . . . . 29

2.17 Grano de recuperacion a nivel de tarea en el sitio Web de Sedan-Bouillon . . . . 30

2.18 Grano de recuperacion a nivel de accion fısica en el sistema MindMap . . . . . . 31

2.19 Adaptacion a la plataforma y al usuario en el sitio Web de Sedan-Bouillon . . . 33

2.20 Adaptacion a la plataforma y al usuario en el sistema Ubidraw . . . . . . . . . . 33

2.21 Adaptacion a la plataforma en el sistema de control de calefaccion . . . . . . . . 34

2.22 Adaptacion a la plataforma en el sistema CamNote . . . . . . . . . . . . . . . . 34

2.23 Adaptacion a la plataforma en el sistema Roomware . . . . . . . . . . . . . . . . 35

2.24 Adaptacion a la plataforma en el sistema ConnecTables . . . . . . . . . . . . . . 35

2.25 Adaptacion a la plataforma en el sistema MindMap . . . . . . . . . . . . . . . . 36

2.26 Meta-IU con negociacion en el sitio Web de Sedan-Bouillon . . . . . . . . . . . . 38

3.1 Marco de Referencia Unificado para Interfaces de Usuario Multi-Objetivo . . . . 44

3.2 Estructura del modelo arquitectural de referencia CAMELEON-RT . . . . . . . 50

3.3 Marco conceptual de Plasticidad Explicita Colaborativa . . . . . . . . . . . . . . 55

3.4 Marco para la Adaptacion de la Conciencia de Contexto en Despliegues Publicos 57

3.5 Diagrama de clases de la arquitectura Vistas de Contexto Hybreed . . . . . . . . 59

3.6 Marco Generico de Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

3.7 Arquitectura conceptual del marco generico de contexto . . . . . . . . . . . . . . 64

4.1 Escenarios y aplicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

4.2 Uso de las palabras deıcticas “in this paragraph” (en la forma de una liga dehipertexto) por parte de Isaac en la herramienta de la mensajerıa instantaneapara referirse a un parrafo en el editor colaborativo . . . . . . . . . . . . . . . . 82

4.3 Uso de las palabras deıcticas “in this diagram” (en la forma de una liga de hiper-texto) por parte de Alice en la herramienta de la mensajerıa instantanea parareferirse a la Fig. 1 del pizarron multi-usuario . . . . . . . . . . . . . . . . . . . 83

4.4 Se sugiere a Sandy e Isaac seguir la conversacion de Alice y Jenny porque ellasestan modificando la figura referenciada por el parrafo que ellos estan modificando 84

INDICE DE FIGURAS xiii

4.5 Se sugiere a Alice y Jenny seguir la conversacion de Sandy e Isaac porque ellosestan reescribiendo el parrafo que refiere a la figura que ellas estan modificando . 85

4.6 Eleccion de participantes y sus roles en la creacion del mapa mental . . . . . . . 93

4.7 Vista del mapa mental cuando el colaborador asume el rol de revisor . . . . . . 94

4.8 Vista del mapa mental cuando el colaborador asume el rol de autor . . . . . . . 95

4.9 Adaptabilidad de la interfaz de usuario del editor de mapas mentales con baseen la configuracion de grupo y las dimensiones de la pantalla de despliegue . . . 96

4.10 Vista detallada en los dispositivos moviles de los colaboradores distribuidos . . . 97

4.11 Disponibilidad y medios de contacto al inicio de la sesion colaborativa. . . . . . 107

4.12 Disponibilidad y medios de contacto de Sandy, Isaac y Alice una vez que Sandyha cambiado su actividad. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

4.13 IU del administrador de contenidos . . . . . . . . . . . . . . . . . . . . . . . . . 116

4.14 Adaptabilidad de la interfaz de usuario de la herramienta de votacion de acuerdoa la ubicacion del grupo y al rol de votantes . . . . . . . . . . . . . . . . . . . . 123

4.15 Opciones establecidas por el colaborador proponente en el pizarron blanco inter-activo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

4.16 Adaptabilidad de los resultados de votacion de acuerdo a la localizacion de losvotantes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

5.1 Contexto de uso de los sistemas colaborativos . . . . . . . . . . . . . . . . . . . 131

5.2 Diagrama de clases del observador . . . . . . . . . . . . . . . . . . . . . . . . . . 134

5.3 Mecanismo para determinar entre dos colaboradores su similaridad de actvi-dades, la disponibilidad y los medios de contacto . . . . . . . . . . . . . . . . . . 138

5.4 Mecanismo para ocultar, sustituir o mostrar funcionalidades y/o componentes . 144

5.5 Creacion de hiperligas desde la mensajerıa instantanea . . . . . . . . . . . . . . 145

5.6 Visualizacion de documentos en forma de arbol . . . . . . . . . . . . . . . . . . 147

5.7 Mecanismo de tipos de trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

5.8 Capas del marco XARE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

xiv INDICE 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 implementacion de los marcos estudiados . . . . . . . . 66

3.3 Analisis de los marcos con relacion al contexto de uso . . . . . . . . . . . . . . 68

3.4 Analisis de adaptacion y contexto en los marcos presentados . . . . . . . . . . . 71

5.1 Similaridad entre las actividades de dos colaboradores . . . . . . . . . . . . . . . 139

5.2 Estado de disponibilidad del colaborador observado respecto a un colaboradorobservador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

5.3 Proximidad logica entre dos colaboradores dentro del espacio compartido . . . . 148

5.4 Sugerencia para llevar a cabo cuatro escenarios . . . . . . . . . . . . . . . . . . . 154

xv

xvi LISTA DE TABLAS

Capıtulo 1

Introduccion

1.1 Trabajo Cooperativo Asistido por Computadora

En 1984, el Trabajo Cooperativo Asistido por Computadora (TCAC) se vuelve un campo deinvestigacion durante un taller (workshop) organizado en Massachussets Institute of Technology.Este campo de investigacion busca comprender las caracterısticas del trabajo cooperativo, con elfin de disenar tecnologıa computacional adecuada para soportarlo. Para lograr este fin, TCACreagrupa el conocimiento de una amplia gama de disciplinas, e.g., la psicologıa, la sociologıa,la informatica y las comunicaciones, que tienen diferentes intereses de acuerdo con su campode estudio.

Un analisis historico muestra que estas disciplinas evolucionaron separadamente durante laprimera decada de la existencia de TCAC. Ası, los computologos se centraron en los principiosde diseno y en las estrategias de implementacion de sistemas colaborativos, mientras que lospsicologos y sociologos se interesaron en el estudio de grupos de colaboracion sin importar sidisponıan o no de soporte tecnologico. Sin embargo, estas disciplinas son mas conexas de lo queparecen [Dourish, 1996]. De hecho, los principios de diseno y las estrategias de implementaciontienen un impacto significativo en la forma de trabajo adoptada por los colaboradores.

Dentro de una organizacion, se puede distinguir tres tipos de procesos cooperativos con-forme a los cuales se han disenado [Yongwu and Haake, 1999] diferentes tipos de aplicacionesy herramientas colaborativas:

• la coordinacion se refiere a que una accion individual da significado a las acciones deotros, las cuales a su vez contribuyen a la realizacion de dicha accion individual paralograr una meta final. La coordinacion requiere de la sincronizacion de las personas yacciones, ası como de la coherencia de las acciones individuales con respecto al procesocompleto;

• la colaboracion es un proceso donde las personas trabajan conjuntamente en la eje-

1

2 Introduccion

cucion de una cierta actividad para crear un producto final. Al termino del proceso, lacontribucion individual no queda aislada, ya que el resultado final es mayor que la sumade todas las contribuciones individuales (sinergia). Por lo tanto, la comprension colectivade los objetivos y del conocimiento compartido es un factor fundamental;

• la decision conjunta se refiere a que las personas contribuyen a tomar colectivamenteuna decision. La consideracion del estatus en el contexto de la decision conjunta es rele-vante, i.e., todos los participantes pueden tener la misma posicion social en el proceso dedecision o pueden hacer sus contribuciones con base en su rol especıfico. La credibilidad,el conocimiento compartido y la comprension colectiva tambien son factores crıticos eneste contexto.

Para efectuar una tarea especıfica (e.g., produccion conjunta de documentos) es necesariorealizar algunas combinaciones de estos procesos cooperativos, requiriendo un mayor o menorgrado de conocimiento compartido o de sincronizacion.

Las situaciones mas frecuentes en un trabajo cooperativo corresponden a la co-localizacion,co-acceso, co-recomendacion y co-depedencia. Por ejemplo, mientras los miembros de un grupotrabajan en una sala de juntas (co-localizacion), ellos pueden acceder y manipular los mismosdocumentos (co-acceso) y senalar informacion relevante (co-recomendacion), de manera que lastareas en las que estos colaboradores esten inmersos son dependientes de dichos documentos(co-dependencia).

La co-localizacion ocurre cuando dos o mas personas, objetos o dispositivos estan fısica ovirtualmente cercanos unos de otros. El co-acceso denota la situacion en donde varias personasaccedan al mismo objeto (un documento o un dibujo); la co-recomendacion denota la situacionen la que las acciones explicitas o implıcitas de los colaboradores son usadas para sugeririnformacion util en la realizacion de sus tareas comunes. Finalmente, la co-dependencia serefiere a la relacion existente entre varias tareas, objetos y usuarios [Haake et al., 2010].

Durante la ultima decada, se han realizado grandes inversiones en aplicaciones cooperativastanto en el sector publico como en el sector privado. Muchas de estas aplicaciones han sidoexitosas, e.g., Lotus Notes de IBM y PoliTeam [Sohlenkamp et al., 2000], pero algunas han sidototalmente lo contrario. Existen varias razones que han conducido al fracaso de algunas de estasaplicaciones, 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 intuicion para administrar aplicaciones cooperativas; y 3) la dificultad extremapara evaluar estas aplicaciones.

Tradicionalmente, el campo del TCAC ha dado lugar a aplicaciones costosas que han sidoimplantadas en el Intranet de una companıa o en Internet. La tendencia actual de muchasaplicaciones colaborativas es hacia Internet, ya que es un medio relativamente accesible encualquier lugar y en cualquier momento. De esta manera, resulta mas facil para las personascomunicar, coordinar y realizar tareas colaborativas independientemente de las fronteras glo-bales. Sin embargo, la principal desventaja de Internet como medio para implantar aplicaciones

Capıtulo 1 3

colaborativas es el riesgo de seguridad, razon por la cual muchas companıas prefieren las solu-ciones en Intranet. A pesar de esta desventaja, Internet ofrece masivas oportunidades a nuevosvendedores de aplicaciones colaborativas para comercializar y poner a disposicion de la gentesus versiones libres (e.g., Dropbox).

1.2 Interaccion Humano-Computadora

Este campo de investigacion se interesa en el diseno, la evaluacion y la implementacion desistemas de computo interactivos para uso humano, ası como en el estudio de los fenomenosprincipales que los rodean [Raskin, 1994]. Los principales objetivos del campo de InteraccionHumano-Computadora (IHM) son: 1) mejorar las interacciones entre usuarios y computadoras,y 2) lograr que estas ultimas se vuelvan cada vez mas usables y receptivas a las necesidades delusuario. Particularmente, este campo de investigacion se centra en el estudio y desarrollo de:1) metodologıas y procesos para disenar interfaces bajo restricciones dadas (usuarios y tareas),pero que aseguren una caracterıstica deseada, e.g., facilidad de aprendizaje o eficiencia de uso;2) metodos para implementar interfaces, e.g., cajas de herramientas, librerıas y algoritmoseficientes; 3) tecnicas para evaluar y comparar interfaces; 4) nuevas interfaces y tecnicas deinteraccion, ası como 5) modelos de descripcion/prediccion y teorıas de interaccion.

Un objetivo a largo plazo de IHM es disenar sistemas que minimicen la barrera entre el modelocognitivo humano de lo que el usuario quiere realizar y la comprension de la tarea del usuario porparte de la computadora. A este respecto, las investigaciones en IHM se centran en desarrollarnuevas metodologıas de diseno, en experimentar con nuevos dispositivos de hardware, en crearprototipos de sistemas de software nuevos, en explorar nuevos paradigmas de interaccion y endesarrollar modelos y teorıas de interaccion.

Diversas metodologıas que resumen tecnicas para el diseno de interfaces de usuarios hanemergido desde la identificacion de este campo de investigacion en 1980. La mayorıa delas metodologıas de diseno provienen de un modelo que describe como interactuan usuarios,disenadores y sistemas.

Las primeras metodologıas trataron los procesos cognitivos de los usuarios como predeciblesy cuantificables. Asimismo, estas metodologıas motivaron a los disenadores de interfaces deusuario a observar los resultados de la ciencia cognitiva en areas como “memoria” y “atencion”.Por el contrario, los modelos modernos se enfocan en una constante realimentacion y conver-sacion entre usuarios, disenadores e ingenieros y promueven que los sistemas esten a la mercedde los tipos de experiencias que los usuarios quieren tener, en vez de poner las experiencias delusuario a la merced del sistema.

El diseno centrado en el usuario es una filosofıa de diseno moderna y ampliamente practicada,cuya base se centra en la idea de que los usuarios deben ser el “centro del escenario” en el disenode cualquier sistema de computo. Usuarios, disenadores y tecnicos trabajan conjuntamentepara articular las preferencias, necesidades y limitaciones de los usuarios y para desarrollar

4 Introduccion

sistemas que satisfagan sus requerimientos. Con frecuencia, los proyectos de diseno centradosen el usuario son influenciados por estudios etnograficos de los entornos donde tendra lugar lainteraccion usuario-sistema.

Modalidad y multimodalidad

El termino multimodalidad proviene de la palabra modalidad. En psicologıa cognitiva, lamodalidad [Vanderdonckt, et al., 2008] denota un sentido humano (vista, tacto, oıdo, olfato ygusto). Otros autores definen la modalidad como un modo de comunicacion dependiente de lossentidos humanos o de los dispositivos de entrada. Existen algunas modalidades que intentanser parecidas a los sentidos humanos, e.g., camara-vista, sensor tactil-tacto, microfono-oıdo,olfativos-olor e incluso el gusto [Legin et al., 2005, Jaimes and Sebe, 2005]. Otras correspondena los dispositivos de entrada tradicionales, e.g., teclado, raton y pantalla tactil.

En el ambito computacional, el termino de modalidad permite representar informacionusando un medio fısico y una forma de representacion. En particular, la forma de representacionadmite que las personas utilicen diferentes modalidades para representar la informacion en elmismo medio fısico, por lo tanto se usa el mismo sentido humano, e.g., considere la luz como unmedio fısico y la vision como un sentido. Se usa la vision para percibir diferentes modalidadesde informacion, e.g., texto, imagenes y expresiones faciales [Vanderdonckt, et al., 2008].

Una definicion formal de modalidad se muestra en la expresion (1.1), en donde la modali-dad (M) es la pareja integrada por un lenguaje de interaccion (L) y un dispositivo fısico (d)[Vanderdonckt, et al., 2008]:

M ::=< L, d > (1.1)

Un lenguaje de interaccion (L) define un conjunto de expresiones bien formadas (i.e., unacadena de sımbolos) que transmiten un significado . La generacion de uno o varios sımbolosresulta de las acciones efectuadas sobre los dispositivos fısicos. Un dispositivo fısico (d) esun elemento de la plataforma anfitriona del sistema interactivo que se comporta como unrecurso de interaccion, ya que adquiere (dispositivo de entrada) o entrega (dispositivo de salida)informacion. Algunos ejemplos de modalidad se presentan a continuacion:

• discurso=<pseudo-lenguaje natural NL, microfono> (cf. Expresion 1.1), dondediscurso es una modalidad compuesta por un pseudo-lenguaje natural NL (lenguajede interaccion) y un microfono (dispositivo);

• escrito a maquina=<pseudo-lenguaje natural NL, teclado>, donde escrito a

maquina representa una modalidad conformada por un pseudo-lenguaje natural NL

(lenguaje de interaccion) y un teclado (dispositivo);

• discurso=<pseudo-lenguaje natural NL, altavoz>, donde discurso es una modal-idad que contiene un pseudo-lenguaje natural NL (lenguaje de interaccion) y unaltavoz (dispositivo);

Capıtulo 1 5

• grafico=<lenguaje grafico GL, pantalla>, donde grafico representa una modali-dad, lenguaje grafico GL corresponde al lenguaje de interaccion y pantalla concierneal dispositivo.

• manipulacion directa=<lenguaje de manipulacion ML, raton>, dondemanipulacion directa corresponde a una modalidad, lenguaje de manipulacion ML

representa el lenguaje de interaccion y finalmente, raton denota al dispositivo.

Una modalidad puede desempenar el papel de un dispositivo de entrada para producir frasesde un lenguaje de interaccion. Por ejemplo, las palabras de una frase de un pseudo-lenguajenatural pueden ser producidas por la seleccion de palabras desde un menu flotante utilizando unraton. En este caso, el teclado es remplazado por la modalidad <seleccion desde menu flotante,raton>. La definicion general de una modalidad se refleja en la expresion (1.2), en donde L es unlenguaje de interaccion, 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 anos la definicion de multimodalidad, asıcomo sus usos, sin llegar a un consenso. En el ambito de IHM, la multimodalidad ha sidodefinida de varias maneras, algunas de ellas se citan a continuacion:

• es la interaccion de multiples tecnicas que involucran varios sentidos humanos si-multaneamente [Vanderdonckt, et al., 2008];

• responde a las entradas de mas de una modalidad o canal de comunicacion, e.g., discursos,gestos y escritura [Jaimes and Sebe, 2005];

• coordina el proceso de entradas multimodales (e.g., el habla, el tacto, las gesticulacionesmanuales, la mirada, los movimientos de cabeza y el cuerpo) con sistemas multimedia desalida [Oviatt, 1999].

Los sistemas multimodales se diferencian en la forma de combinar las modalidades, de maneraque existen dos tipos de sistemas multimodales: de entrada o de salida. Un sistema multi-

modal de entrada combina de manera coordinada dos o mas modos de entradas con un sis-tema multimedia de salida. Por ejemplo, el sistema MultimodaliXML [Stanciulescu et al., 2005]permite que el usuario ingrese informacion al sistema a traves de una interaccion grafica, vo-cal y/o tactil. Un sistema multimodal de salida presenta la informacion combinando doso mas modalidades de comunicacion, e.g., el sistema de neurocirugıa llamado The AssistedNeuro-surgery System utiliza graficos y audio [Vanderdonckt, et al., 2008].

Las modalidades de entrada se dividen en dos grupos (cf. Figura 1.1): el primero esta basadoen los sentidos humanos (e.g., vista, tacto y oıdo) y el segundo corresponde a los dispositivos

6 Introduccion

de entrada (e.g., raton y teclado). La multimodalidad sirve como entrada a las aplicaciones pormedio de las interfaces de usuario. Las aplicaciones que utilizan la multimodalidad conciernenprincipalmente a las de colaboracion remota, reuniones, entre otras [Jaimes and Sebe, 2005].

Figura 1.1: Vision general de la interaccion multimodal mediante un enfoque centrado en elusuario

1.3 Contexto de investigacion

Este tema de tesis doctoral se inscribe en el campo de investigacion del Trabajo CooperativoAsistido por Computadora (TCAC). Como se menciona en la seccion 1.1, este campo mul-tidisciplinario estudia tanto los aspectos sociales de las actividades individuales y colectivas,como los aspectos tecnologicos de la informacion y de las comunicaciones, con el fin de asistirla colaboracion entre personas potencialmente distribuidas [Dourish, 1996].

En relacion con el caracter multidisciplinario de TCAC, este proyecto de investigaciontoma principalmente la perspectiva de la informatica y de las comunicaciones, con el objetode modelar, disenar e implementar una infraestructura que facilite el desarrollo de sistemascooperativos (cf. Figura 1.2). Estos sistemas proveen espacios de trabajo que permiten alos colaboradores comunicarse entre si, producir conjuntamente informacion compartida ycoordinar sus actividades, aun cuando no puedan reunirse fısicamente en el mismo lugar y/oal mismo tiempo.

TCAC contempla varios dominios de aplicacion. Particularmente, este proyecto detesis abordara el dominio de aplicacion de la produccion cooperativa de documentos.Aun si numerosos trabajos de investigacion se han consagrado al estudio de este do-minio de aplicacion, 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 produccion

Capıtulo 1 7

Figura 1.2: Contexto de investigacion de este proyecto doctoral

cooperativa de documentos es un problema recurrente. Los sistemas cooperativos que soportaneste dominio de aplicacion deben permitir a grupos de coautores planificar sus tareas, ası comoproducir, revisar y comentar sus contribuciones. Aunque este dominio de aplicacion haga in-tervenir grupos consecuentes de coautores, algunos estudios sociologicos muestran que se tratade pequenos grupos que varıan entre dos y cinco individuos [Beck, 1993].

El fenomeno de la globalizacion no solamente ha dado lugar a la distribucion de organi-zaciones, sino tambien a la colaboracion entre organizaciones localizadas en diferentes partesdel mundo. En consecuencia, las personas necesitan trabajar conjuntamente a pesar de ladistancia y de la eventual restriccion de poder reunirse al mismo tiempo a causa de las difer-encias horarias [Gall and Hauck, 1997]. En respuesta a este requerimiento, este proyecto deinvestigacion pretende proveer soportes para la interaccion distribuida mediante dispositivos decomputo diversos, e.g., pizarrones digitales, PCs, PDAs y smartphones.

Por otra parte, la mayorıa de las herramientas actuales implıcitamente asumen que su in-terfaz de usuario se confina en un solo dispositivo de computo, lo cual implica que el usuariose vuelva sedentario cuando interactua con su PC, mediante dispositivos de E/S tradicionales,e.g., teclado, raton y monitor. Sin embargo, la creciente proliferacion de dispositivos het-erogeneos y el progreso de las redes de comunicacion permiten imaginar al usuario como un“ente que evoluciona en un entorno variado y que utiliza, de manera oportunista, dispositivosfijos y moviles 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 presentacion en todo tipo dedispositivo. Sin embargo, el desarrollo separado de sistemas adaptados a cada contexto de usono solo es extremadamente costoso, en terminos de desarrollo y mantenimiento, sino tambienpuede dar lugar a comportamientos incoherentes. Algunas posibles consecuencias podrıan serla sub-utilizacion de los sistemas y el costo requerido para mantener la consistencia de versiones

8 Introduccion

en multiples dispositivos heterogeneos. La propiedad de “plasticidad” pretende hacer frente aestos problemas (cf. Figura 1.2).

La plasticidad es la capacidad de los sistemas interactivos para adaptarse a un conjuntode contextos de uso, garantizando en todo momento un conjunto de criterios de calidad, e.g.,la usabilidad y la continuidad de interaccion [Calvary et al., 2004]. El termino de plasticidad[Thevenin and Coutaz, 1999] fue introducido, a finales de los noventas, en el dominio de lossistemas interactivos mono-usuario, en respuesta a la creciente diversidad de dispositivos decomputo. Este termino se inspira en la propiedad de los materiales que les permite expandirsey contraerse, sin romperse, bajo restricciones naturales. La plasticidad puede repercutir tantoen los componentes de la interfaz de usuario como en el nucleo funcional del sistema, tal comosucede con el descubrimiento de servicios, e.g., si un usuario se movio hacia un lugar dondeesta disponible un nuevo servicio, este aparecera en su PDA. En este ejemplo, la interfaz deusuario se remodela, con el fin de incorporar este nuevo servicio y de soportar una interaccionoportunista.

1.4 Planteamiento del problema

Vanderdonckt et al. caracterizan el espacio del problema de las interfaces de usuario plasticasmediante siete dimensiones [Vanderdonckt et al., 2008]: 1) percutores de plasticidad, 2) granu-laridad de los componentes de la interfaz de usuario, 3) granularidad del estado de recuperacion,4) despliegue de la interfaz de usuario, 5) contexto de uso, 6) meta-interfaz de usuario y 7) es-pacio tecnologico. Sin embargo, hoy en dıa, no existen sistemas mono-usuario ni colaborativosque comprendan estas siete dimensiones (cf. Capıtulo 2).

A pesar de que las companıas tecnologicas han puesto a disposicion de los usuarios una vari-edad cada vez mas amplia de dispositivos, los cuales difieren en sus caracterısticas fısicas (e.g.,tamano de pantalla, capacidad de memoria e inclusion de camaras, altavoz y teclado) y logicas(e.g., diferentes plataformas y librerıas), en la actualidad no existen sistemas colaborativosplasticos que hagan frente a esta heterogeneidad.

Los pocos sistemas colaborativos plasticos 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 identicas o similares. Aunque, dichos sistemasofrecen algunas propiedades plasticas, e.g., adaptar el area de trabajo al detectar dos tabletsunidas fısicamente, el problema de desarrollar sistemas “a la medida” aparece al momento dequerer agregar una nueva propiedad plastica, ya que esta puede requerir modificaciones en granparte de dichos sistemas. La mejor opcion para crear un sistema colaborativo plastico serıa eluso de un marco de desarrollo (framework) que ofrezca una gama de opciones de adaptacionpre-definidas, pero extensibles.

Si se hace un recuento de los marcos para sistemas mono-usuario plasticos, que estandisponibles a los desarrolladores, podemos observar que aunque todos adordan los elementos

Capıtulo 1 9

del contexto de uso (i.e., usuario, entorno y plataforma), solo unos cuantos consideran algunaforma de adaptacion (i.e., remodelacion, migracion o redistribucion). Por lo tanto, se puedeconstatar que estos marcos no solo estan limitados en cuanto al numero ofertado, sino tambienrespecto a las dimensiones plasticas consideradas.

Los marcos que pretenden facilitar el desarrollo de Sistemas Colaborativos Plasticos (SCP)solo se preocupan por cubrir algunos elementos del contexto de uso. Sin embargo, una de lasprincipales limitaciones de dichos marcos reside en el uso del concepto de “contexto de uso”, talcomo fue definido para sistemas mono-usuario. Por obvias razones, dicho concepto no consideralos requerimientos propios de los sistemas colaborativos como, por ejemplo, la intervencion demultiples usuarios, el uso compartido de recursos fısicos y virtuales y la provision de informacionde conciencia de grupo para conformar un entorno comun.

Asimismo, la mayorıa de los marcos SCP ofrecen unicamente un soporte conceptual, el cualresulta difıcil de entender y aplicar durante las fases de diseno e implementacion. Los pocosmarcos que proveen un soporte de implementacion solo abordan de manera muy limitada ladimension del contexto de uso, dejando completamente de lado las otras seis dimensiones delespacio del problema de las interfaces de usuario plasticas.

Ninguno de los marcos SCP satisface la necesidad ineludible de recuperacion de informacion,cuando esta se pierde al momento de pasar de un contexto de uso a otro. La informacion norecuperada es de vital importancia, puesto que puede ser el resultado de varias horas de trabajo.

La mayorıa de los marcos SCP solo ofrece un percutor de plasticidad que actua de maneraestatica sobre una granularidad fija de la interfaz de usuario. Este unico percutor permiteque algunos componentes de la interfaz de usuario se remodelen, se redistribuyan en variosdispositivos o bien migren de un dispositivo a otro para adaptarse al nuevo contexto de uso.Ademas, dicho percutor actua sobre una granularidad fija de la interfaz de usuario, i.e., a nivelde interactor (e.g., icono), a nivel de tarea (e.g., una ventana de impresion) o bien a nivel de lainterfaz de usuario completa (e.g., transformacion de una forma textual a una grafica). Dadoque dichos marcos SCP no ofrecen todas las opciones resultantes de la combinacion de estasdos dimensiones (i.e., percutores de plasticidad y granularidades de la interfaz de usuario), lasposibles interfaces de usuario son generadas de manera estatica.

Finalmente, algunos marcos SCP exploran la meta-interfaz de usuario de manera muy lim-itada ya que dejan, como cuestiones abiertas, las meta-interfaces de usuario plasticas y sinnegociacion, i.e., aquellas en las que no se requiere la intervencion del usuario en el proceso deadaptacion, dado que el sistema es capaz de adaptarse de manera autonoma.

10 Introduccion

1.5 Objetivos del proyecto

Objetivo general

Analizar los requerimientos y los posibles enfoques de solucion propuestos en el estado delarte para dotar a los sistemas cooperativos de propiedades plasticas. A partir de este analisisse proponen soluciones, tanto a nivel teorico como a nivel practico, que faciliten el desarrollode sistemas capaces de solucionar algunos problemas de las interfaces de usuario plasticasmultimodales.

Objetivos particulares

1. Redefinir el concepto de “contexto de uso” propuesto en el dominio de los sistemas mono-usuario para adaptarlo al dominio de los sistemas cooperativos.

2. Desarrollar un modelo conceptual de plasticidad que sirva como instrumento de referenciapara ayudar a los desarrolladores en el proceso de construccion de sistemas cooperativosplasticos.

3. Con base en los conceptos, principios y mecanismos propuestos en el modelo conceptualde plasticidad, se pretende disenar un marco de desarrollo (framework) que facilite:

(a) la adaptacion de sistemas cooperativos a diferentes contextos de uso que contemplentodos o algunos elementos (usuario, entorno y plataforma);

(b) la creacion de meta-interfaces que involucren a los usuarios en el proceso deadaptacion como observadores o como entes activos, segun convenga;

(c) la remodelacion y redistribucion de la interfaz de usuario de estos sistemas;

(d) el uso de diferentes granularidades de adaptacion (total, espacio de trabajo, interac-tor y pixel), y

(e) la recuperacion del estado de dichos sistemas a nivel sesion, tarea y accion.

4. Validar el marco propuesto mediante el desarrollo de algunas aplicaciones de edicioncooperativa para poner en evidencia sus alcances y limitaciones.

1.6 Organizacion del documento

La organizacion de este documento se resume en la figura 1.3. El capıtulo 1 corresponde a estaintroduccion en donde se dio un panorama general de la problematica a resolver, ası como losobjetivos a cumplir en este proyecto de investigacion.

Capıtulo 1 11

Introducción

Validación

Conclusiones

Capítulo 1

Capítulo 6

Capítulo 7

Estado del arte

Contribuciones

Capítulo 2

Capítulo 4

Capítulo 3

Capítulo 5

Figura 1.3: Organizacion del documento

Tanto el capıtulo 2 como el capıtulo 3 presentan el estado del arte. En particular, el capıtulo2 describe las dimensiones del espacio del problema de las interfaces de usuario plasticas, lascuales han sido ejemplificadas mediante ocho aplicaciones representativas. Dado que dichasdimensiones fueron identificadas en el dominio de los sistemas mono-usuario, en el capıtulo 3se detallan los marcos mas relevantes para el desarrollo de este tipo de sistemas. Asimismo,en el capıtulo 3, se describen los principales marcos de desarrollo para sistemas colaborativosplasticos, con la finalidad de analizar los avances logrados en ambas vertientes.

El marco XARE (conteXt-Aware groupwaRE), propuesto en tesis, pretende orientar a losdesarrolladores en la creacion de sistemas cooperativos plasticos. El analisis de este marcose describe en el capıtulo 4, el cual inicia presentando una definicion de los elementos queconforman el contexto de uso en sistemas cooperativos. A continuacion, se proponen variosescenarios que ponen en evidencia algunas dimensiones del espacio del problema de las interfaces

12 Introduccion

de usuario plasticas. La mayorıa de estos escenarios son ejemplificados mediante aplicaciones.Algunas de estas son prototipos que sirvieron de base para disenar e implementar el marcopropuesto.

En el capıtulo 5, se expone primeramente la reconceptualizacion del contexto de uso parael dominio de los sistemas cooperativos. Para realizar dicha reconceptualizacion, se hizouso del patron de diseno Decorador, el cual permite a los desarrolladores anadir y suprimirdinamicamente contextos de uso en un sistema cooperativo. Tambien se incluyen los diagramasde clases generados a partir de algunos escenarios. La mayorıa de las propuestas de adaptacional contexto, que se ponen en evidencia en dichos escenarios, han sido concretizadas en formade mecanismos. Finalmente, se describen las capas que conforman el marco XARE.

El capıtulo 6 presenta la validacion del marco XARE. En particular, se define la API quepermite la comunicacion entre las capas de dicho marco y entre los componentes de cada capa.Para hacer mas claro el funcionamiento de dicho marco, se muestra el flujo de informacion paraalgunos de los escenarios analizados, en especıfico para aquellos que han sido explorados conmayor profundidad.

En el capıtulo 7, se presentan las conclusiones derivadas del trabajo desarrollado, ası comoalgunas ideas de trabajo a futuro que ayudarıan a mejorar el marco XARE.

Capıtulo 2

Interfaces de usuario plasticas en

sistemas interactivos

En el presente capıtulo se estudian las interfaces de usuario plasticas, las cuales tienen origen enel area de Interaccion Humano-Computadora. El analisis realizado en este apartado consideravarias dimensiones que podrıan ser tratadas cuando se implementa la propiedad de plasticidaden sistemas interactivos, e.g., informar o consultar al usuario acerca de los cambios necesariospara adaptarse al nuevo contexto de uso. Las dimensiones a considerar se han dividido endos grandes partes que se consideran relevantes para este trabajo de investigacion. La primeraparte estudia las siete dimensiones de las interfaces plasticas propuestas en el dominio delos sistemas interactivos mono-usuario (cf. seccion 2.1-2.8). La segunda parte analiza lasdimensiones desarrolladas en el ambito de los sistemas conscientes de contexto (cf. seccion2.9). Para ejemplificar dichas dimensiones, se consideran varios sistemas interactivos, los cualesestan enfocados en apoyar el trabajo individual o el grupal. Finalmente, se presentan lasconclusiones de este capıtulo (cf. seccion 2.10).

2.1 Problemas encontrados en las interfaces de usuario

plasticas multi-modales

Como se menciono en el capıtulo 1, la interfaz de usuario de un sistema interactivo no puede serla misma para un dispositivo pequeno (e.g., una PDA) que para uno grande (e.g., un pizarronelectronico); el problema se agudiza si se consideran las demas caracterısticas de hardware (e.g.,capacidades de procesamiento, almacenamiento y comunicacion) y software (e.g., sistema ope-rativo y lenguajes de programacion soportados) de dicho dispositivo. Por lo tanto, la ejecucionde un sistema interactivo en diferentes dispositivos genera varios inconvenientes que puedenconvertirse en un problema de grandes dimensiones al agregar otras variantes, e.g., habilitaro deshabilitar funcionalidades a un usuario, dependiendo de su ubicacion virtual dentro de un

13

14 Interfaces de usuario plasticas en sistemas interactivos

documento.

Vanderdonckt et al. han identificado las siguientes siete dimensiones para adaptar una inter-faz de usuario (IU) a cambios en el contexto de uso (cf. Figura 2.1) [Vanderdonckt, et al., 2008]:

• Percutores de plasticidad: permiten cambiar la presentacion de la IU mediante re-modelacion, redistribucion y migracion de componentes;

• Granularidad de la IU: representa la unidad mas pequena de la IU que puede seradaptada; la granularidad puede ser a nivel de pıxel, de interactor (e.g., un ıcono), deespacio de trabajo o de aplicacion;

• Granularidad de recuperacion del estado: se refiere al estado del sistema, despuesde la adaptacion; la recuperacion del sistema puede ser a nivel de sesion, de tarea o deaccion;

• Despliegue de la IU: indica la forma en que la IU lleva a acabo la adaptacion; estadimension contempla dos formas: estatica o dinamica;

• Contexto de uso: plantea las causas que provocan la adaptacion del sistema; los factorespara realizar la adaptacion son provocados por cambios en el usuario, en el entorno o enla plataforma;

• Espacio tecnologico (ET): caracteriza el grado de heterogeneidad tecnica soportadapor 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 elproceso de adaptacion; la meta-IU puede ser implementada con negociacion o sin ne-gociacion; otra cuestion importante, la cual sigue abierta, es aplicar plasticidad a unameta-IU para que pueda adaptarse a los cambios contextuales.

Las dimensiones de la Figura 2.1 seran ejemplificadas mediante ocho sistemas interactivos,los cuales seran descritos de forma concisa a continuacion.

El sitio Web Sedan-Bouillon, que promueve las ciudades de Sedan y Bouillon, tiene comocaracterıstica primordial permitir a los usuarios participar en la redistribucion entre una PC yuna PDA de la pagina principal para facilitar la navegacion [Balme et al., 2005].

El sistema de control de calefaccion permite al usuario controlar la temperatura de algunoscuartos de su casa, usando dispositivos heterogeneos, e.g., PDA, PC, telefono movil y reloj depulso [Coutaz and Calvary, 2008].

El sistema FlexClock no solo provee diecisiete configuraciones predefinidas de los componentesde la fecha y de la hora, sino tambien permite adaptar tales componentes al tamano de laventana [Grolaux et al,. 2002].

Capıtulo 2 15

Figura 2.1: Espacio del problema de las interfaces de usuario plasticas multimodales

El sistema Ubidraw permite tanto crear dibujos vectoriales como adaptar su IU al tamanode la ventana dependiendo de la tarea actual (e.g., el ultimo icono que fue seleccionado), lafrecuencia de la tarea (e.g., la cantidad de clics sobre cada ıcono) y la preferencia del usuariopor una tarea (e.g., la posicion del icono dentro de las preferencias/necesidades del usuario)[Vanderdonckt and Gonzalez-Calleros, 2008].

El sistema CamNote esta compuesto de dos espacios de trabajo: uno contiene un visor dediapositivas y el otro comprende tanto un panel de control para navegar entre las diapositivascomo un editor de notas. Ambos espacios de trabajo despliegan como fondo el video delusuario en tiempo real. La caracterıstica principal de CamNote es dividir dinamicamente suIU entre dispositivos heterogeneos (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 seenfocan en el trabajo grupal, cuyos miembros estan colocalizados. El sistema Roomware agregacapacidades de computo y comunicacion a objetos reales, e.g., paredes, mesas y sillones, con lafinalidad de explorar nuevas formas de interaccion entre los colaboradores [Prante et al., 2004].Los componentes de interaccion de Roomware son tres: 1) Dynawall, 2) InteracTable y 3)CommChair. Dynawall esta compuesto por tres pizarrones electronicos, empotrados en la


pared, que forman un dispositivo largo y sensible al contacto. InteracTable es una pantallasensible al contacto colocada en la parte superior de una mesa. Finalmente, CommChaircombina la movilidad y el confort de una silla con la funcionalidad de una computadora.

El sistema ConnecTables facilita la transicion del trabajo individual al trabajo grupal (yviceversa). Dicha transicion se lleva a cabo cuando dos colaboradores unen sus tablets PCpara crear dinamicamente un espacio de trabajo compartido, donde los colaboradores puedenarrastrar las imagenes desde una tablet hacia la otra [Tandler et al., 2001].

El ultimo sistema a considerar es MindMap que sirve para crear, editar y visualizar mapasmentales usando telefonos celulares. La manera de utilizar estos dispositivos rompe con elparadigma de uso personal. Los aparatos telefonicos pueden ser conectados de manera vertical(alineados entre ellos) o de manera perpendicular (en forma de T). Una caracterıstica impor-tante de este sistema es el escalamiento del mapa mental mostrado en pantalla, i.e., cuandoel dispositivo esta sobre la mesa, el mapa mental tiene una escala de 1:1; en cambio cuandoesta en la mano del colaborador, la escala es menor de 1:1 con el objetivo de que el mapa seavisualizado completamente en una unica pantalla [Lucero et al., 2010].

2.2 Percutores de plasticidad

La adaptacion del sistema al contexto de uso (plataforma, entorno o usuario) puede tomarmultiples formas. En esta seccion se explica como percibe un usuario la adaptacion del sistema.La adaptacion puede llevarse a cabo al aplicar uno o varios de los siguientes percutores deplasticidad: remodelacion, redistribucion y migracion de la IU [Coutaz and Calvary, 2008].

2.2.1 Remodelacion

La remodelacion de la IU denota cualquier reconfiguracion que es perceptible al usuario y queresulta de la aplicacion de una o mas transformaciones sobre toda o una parte de la IU. Lastransformaciones incluyen [Vanderdonckt, et al., 2008, Coutaz and Calvary, 2008]:

• Insercion de nuevos componentes: proporciona acceso a los nuevos servicios rele-vantes en el nuevo contexto de uso o situacion, e.g., si existe mas espacio disponible en lapantalla se podra exhibir mas informacion util;

• Eliminacion de componentes: suprime componentes que sean irrelevantes en el nuevocontexto de uso o situacion, e.g., remover los componentes innecesarios de la IU para undeterminado rol;

• Sustitucion de componentes: reemplaza algunos componentes por otros. La susti-tucion puede verse como la combinacion de insercion y eliminacion, e.g., conversion deun menu fijo en uno flotante;

Capıtulo 2 17

• Reorganizacion de los componentes: revisa la disposicion y las dependencias tem-porales de los componentes. La reorganizacion puede resultar de la insercion, eliminaciono sustitucion de componentes de la IU, e.g, la sustitucion de un componente puede verseal reducir una lista completa en una lista desplegable, si el usuario cambia de una PC auna PDA. La reorganizacion puede afectar diversas partes de la IU, e.g., la reorganizacionde una pagina Web puede afectar de manera independiente al estilo, a la disposicion, alcontenido, a la estructura, a la navegacion, ası como a la modalidad inicial de la pagina;

• Degradacion: debido a un cambio de plataforma computacional se reorganiza la IU, lacual pasa de una plataforma limitada a una aun mas limitada, e.g., de una PC a un PDAo de un screen phone tomada de un video1 a un telefono movil. La gradacion ascendentees el proceso inverso que consiste en mejorar la IU cuando el usuario cambia de unaplataforma limitada a una menos limitada.

La remodelacion de una IU puede implicar cambios en el sistema de modalidades y/o cambiosen 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 abstraccion, los cuales sedescriben a continuacion [Vanderdonckt, et al., 2008, Calvary et al., 2006]:

• Intra-modal: los componentes de la IU que necesitan ser remodelados (IU fuente) seredefinen en la misma modalidad, e.g., si la IU fuente es multi-modal, entonces la IUobjetivo tambien sera multi-modal, i.e., la remodelacion intra-modal no provoca ningunaperdida en las modalidades establecidas. En este caso, la modalidad se preserva, e.g., degrafico a grafico;

• Inter-modal: los componentes de la IU fuente se redefinen en una modalidad diferente.Esta transformacion puede engendrar la perdida 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 combinacion de transformaciones (intra- e inter- modal), e.g.,la herramienta TERESA [Paterno et. al., 2008] utiliza la modalidad grafica y vocal.

Dado que una modalidad esta definida como M:= ≪ L, d ≫|≪ L, M ≫, en donde M es lamodalidad, L lenguaje de interaccion y d un dispositivo fısico (cf. Seccion 1.2), un cambio dela modalidad puede resultar de [Vanderdonckt, et al., 2008]:

• Una substitucion del dispositivo (a condicion de que el nuevo dispositivo soporte ellenguaje de interaccion original);

1Screen phone es un telefono ubicado en una terminal. http://www.comtek-intl.com/screenphone.htm


• Una substitucion del lenguaje de interaccion (a condicion de que el dispositivo originalpermita el nuevo lenguaje de interaccion);

• Un cambio radical del dispositivo y del lenguaje de interaccion.

Analizando la remodelacion en los sistemas de ejemplo, se puede observar que el sistemade control de calefaccion se reconfigura a nivel inter-modal, ya que la IU tanto de la PCcomo de la PDA se clasifican en la modalidad grafica (cf. Figura 2.2 a y b tomadas de[Coutaz and Calvary, 2008]), mientras que la IU del telefono movil y del reloj pertenecen ala modalidad textual (cf. Figura 2.2 c y d tomadas de [Coutaz and Calvary, 2008]). Todos losdemas sistemas son intra-modales porque sus componentes fuente se reconfiguran dentro de lamisma modalidad grafica.

Modalidad: gráfica

a) PC b) PDA c) Teléfono móvil

d) Reloj digital

Modalidad: textual

Figura 2.2: Remodelacion en el sistema de control de calefaccion

2.2.2 Redistribucion

La redistribucion denota la reasignacion de los componentes de la IU de un sistema a di-versos dispositivos de interaccion. Cuatro tipos de redistribucion han sido identificados[Calvary et al., 2006]:

1. De centralizada a centralizada: conserva el estado centralizado de la IU, e.g., mi-gracion total de la IU de una PC a una PDA;

Capıtulo 2 19

2. De centralizada a distribuida: desmiembra la IU, e.g., reparticion entre una PC y unPDA;

3. De distribuida a centralizada: reconcentra la IU en una sola plataforma;

4. De distribuida a distribuida: cambia el estado de distribucion 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 tareasdel usuario, y

• Plataformas totalmente equivalentes: permiten al usuario realizar una tarea endiferentes plataformas, e.g., tanto en una PC como en una PDA, segun su conveniencia.

Coutaz y Calvary [Coutaz and Calvary, 2008] definen la redistribucion estatica y dinamica.La primera se realiza fuera de lınea entre dos sesiones. Por el contrario, la redistribuciondinamica se produce en tiempo de ejecucion.

Retomando los sistemas de ejemplo, podemos decir que el sitio Web de Sedan-Bouillon so-porta todos los tipos de redistribucion, i.e., distribucion parcial o completa de sus espacios detrabajo (tıtulo del sitio Web, contenido y menu) entre diferentes dispositivos (cf. Figura 2.3tomada de [Balme et al., 2005]). Cuando el sitio Web se ejecuta por completo en una PC o unaPDA, este permanece centralizado (cf. Figura 2.3.a); el sitio Web puede pasar de un estadocentralizado a uno distribuido cuando se divide entre ambos dispositivos, e.g., el menu en laPDA y el contenido en la PC (cf. Figura 2.3.b); posteriormente el sitio Web puede volversea redistribuir al cambiar los componentes de lugar, e.g., el menu en la PC y el contenido enla PDA (cf. Figura 2.3.d). Finalmente, el sitio Web tambien se puede concentrar en un solodispositivo, e.g., en la PC (cf. Figura 2.3.c).

Roomware soporta tres tipos de redistribucion (cf. Figura 2.4 tomada de[Prante et al., 2004]). La IU de este sistema se encuentra centralizada en InteracTable y enCommChair (cf. Figura 2.4.a), pero puede pasar a un estado distribuido cuando la IU esdesplegada en los tres pizarrones electronicos que conforman DynaWall (cf. Figura 2.4.b).Asimismo, Roomware puede pasar de un estado distribuido a uno centralizado cuando concen-tra su IU, que fue previamente desplegada en DynaWall, en InteracTable o CommChair (cf.Figura 2.4.c).

CamNote soporta la redistribucion de centralizada a distribuida y viceversa. Como se men-ciono anteriormente, dicho sistema esta compuesto de dos espacios de trabajo: uno contiene elvisor de diapositivas, mientras que el otro comprende un panel de control para navegar entrelas diapositivas y un editor de notas (cf. Figura 2.5 tomada de [Demeure et al., 2005]). Am-bos espacios de trabajo despliegan como fondo un visor que muestra video en tiempo real del


c) Centralizada (PC)

ContenidoMenúTítulo

Contenido Contenido

Contenido

Menú Menú

Menú

a) Centralizada (PC o PDA) b) Distribuida (PC y PDA)

d) Distribuida (PC y PDA)

Título

Título

Figura 2.3: Todos los niveles de redistribucion en el sitio Web de Sedan-Bouillon

usuario (cf. Figura 2.5.a). Cuando CamNote detecta una pocket PC, el espacio de trabajo quecontiene el panel de control migra de la PC a la pocket PC, mientras que el espacio que contiene

Capıtulo 2 21

a) Centralizada b) Distribuida

c) Centralizada

CommChair InteracTable

InteracTable

DynaWall: tres pizarrones electrónicos

Figura 2.4: Niveles de redistribucion 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 deredistribucion de la IU (i.e., organizacion centralizada) cuando la PC detecta la ausencia de lapocket PC (cf. Figura 2.5.a).

Tanto ConnecTables [Tandler et al., 2001] como MindMap [Lucero et al., 2010] poseen la car-acterıstica de ejecutarse sobre dispositivos del mismo tipo. El primero se ejecuta sobre tablets yel segundo funciona sobre telefonos celulares. Aun con la peculiaridad anterior, ambos soportandos tipos de distribucion: a) de centralizada a distribuida y b) de distribuida a centralizada.Dichas distribuciones son implementadas al momento de acoplar o desacoplar los dispositivosmanipulados por cada sistema. Durante el acoplamiento se crea una sola area de trabajo entrelos dispositivos participantes, pero al separarlos el area de trabajo se concentra en cada dispos-itivo (cf. Figuras 2.6 y 2.7 tomadas de [Tandler et al., 2001] y de un video2, respectivamente).

2Lucero, 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


b) Distribuida (PC y )pocket PCa) Centralizada (PC)

Editor denotas

Visor dediapositivas

Visor dediapositivas

Panel decontrol

Panel decontrol

Figura 2.5: Niveles de redistribucion de CamNote: de centralizada (en una PC) a distribuida(entre una PC y una pocket PC) y viceversa

a) Centralizada b) Distribuida

ConnecTable Acoplamiento de dos ConnecTables

Figura 2.6: Niveles de redistribucion de ConnecTables: de centralizada a distribuida y viceversa

Finalmente, FlexClock, el sistema de control de calefaccion y Ubidraw solo se ejecutan enuna PC.

2.2.3 Migracion

La migracion de la IU de un sistema se refiere a la transferencia total o parcial de sus compo-nentes a los diferentes dispositivos de interaccion activos, sin importar si estos dispositivospertenecen o no a la plataforma actual. La migracion es total si la IU se mueve por completo auna plataforma diferente. Por otra parte, la migracion es parcial cuando solo un subconjunto

Capıtulo 2 23

b) Distribuidaa) Centralizada

Acoplamiento de tres teléfonos celulares

Un teléfono celular

Figura 2.7: Niveles de redistribucion 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 deinteraccion, e.g., cuando se incorpora una PDA, los paneles de control de un editor de graficosmigran a la PDA (migracion a nivel de espacio de trabajo).

La migracion es de dos tipos [Coutaz and Calvary, 2008]:

1. Estatica: cuando se realiza fuera de lınea entre dos sesiones;

2. Dinamica: cuando se produce en tiempo de ejecucion.

Las tecnicas de migracion y redistribucion son diferentes, e.g., una IU centralizada puede serredistribuida, pero no migrable (redistribucion estatica) o una IU centralizada puede migrar,pero si la migracion es total seguira estando centralizada en un dispositivo.

2.3 Granularidad de adaptacion

La granularidad de los componentes de la IU de un sistema denota la unidad mas pequenade software que puede ser afectada por la remodelacion y/o redistribucion, las cuales puedenser totales o parciales [Vanderdonckt, et al., 2008]. Cuando es parcial, la remodelacion y/ola redistribucion se pueden llevar a cabo a nivel de espacio de trabajo, interactor y pıxel. Acontinuacion, 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 cualse define como un espacio que apoya la ejecucion de un conjunto de tareas logicamente


conectadas. Los proyectos Pick and Drop y PebblesDraw ofrecen ejemplos de distribucionde la IU a nivel de espacio de trabajo, el cual esta concretizado por la paleta de colores,el teclado y las imagenes de Pick and Drop y por las notas, los tıtulos y los horarios dePebblesDraw (cf. Figuras 2.8 a y b tomadas de [Rekimoto, 1997, Myers, 2001], respecti-vamente);

• Interactor: es un caso especial del espacio de trabajo, donde la unidad de distribucion esun interactor elemental, e.g., en las superficies aumentadas de Rekimoto (cf. Figura 2.8.ctomada de [Rekimoto and Saitoh, 1999]) los conceptos del dominio, e.g., las mesas y sillasde una herramienta de diseno de interiores pueden ser desplegadas entre computadoraspersonales, 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 multiples su-perficies, e.g., en las superficies aumentadas de Rekimoto, una ventana se despliega sobredos mesas juntas, como si estas fueran controladas por una sola computadora (cf. Figura2.8.c). Es importante hacer notar que esta granularidad solo concierne a la redistribucionde la IU.

a) Pick and drop

c) Superficies aumentadasb) PebblesDraw

Figura 2.8: Grano de adaptacion en otros sistemas interactivos

Capıtulo 2 25

Retomando los sistemas de ejemplo, se puede categorizar el sistema FlexClock a nivel deinteractor, en cuanto a la granularidad de la adaptacion, debido a que sus componentes (horay fecha) son tareas independientes, pero su presentacion (tamano, forma y alineacion) dependedel tamano de la ventana (cf. Figura 2.9 tomada de [Grolaux et al,. 2002]).

Tarea: fecha

Tarea: hora

Figura 2.9: Grano de adaptacion a nivel de tarea en FlexClock

El sistema de control de calefaccion 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 graficano 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 telefono movil o un reloj (cf.Figura 2.10.a). En el caso de la adaptacion a nivel de interactor, la IU desplegada en una PCpresenta una sola vista, mientras que en una PDA la IU es estructurada en tres vistas (una porcuarto) a traves de las cuales el usuario puede navegar usando pestanas (cf. Figura 2.10.b).

El sitio Web de Sedan-Bouillon remodela su IU a nivel de espacio de trabajo porque lapresentacion (tamano, posicion y alineacion) de los componentes de la pagina (tıtulo, con-tenido y menu) es modificada cuando esta es cargada en una PDA (cf. Figura 2.11 tomada de[Balme et al., 2005]).

El sistema Ubidraw tambien transforma su IU a nivel de espacio de trabajo, el cual estarepresentado 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 realizandoel usuario. Ubidraw se adapta al nuevo contexto de uso al cambiar el tamano (e.g., ocultando o


a) Grano de adaptación: Total

b) Grano de adaptación: Interactor

Interfaz textual

Interfaz gráfica

Despliegue en una sola vista

Despliegue en tres vistas

Figura 2.10: Granos de adaptacion a nivel total y de interactor en el sistema de control decalefaccion

mostrando algunos iconos) y la alineacion (e.g., vertical u horizontal) de las barras dependiendode la actual tarea, la frecuencia de la tarea y la preferencia del usuario por alguna tarea (cf.Figura 2.12 tomada de [Vanderdonckt and Gonzalez-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 depresentar el contenido

Menú diferente entamaño y posición

Figura 2.11: Grano de adaptacion a nivel de espacio de trabajo en el sitio Web de Sedan-Bouillon

La barra cambió de posición y de alineaciónRetoucher

La barra ocultó sus iconosOptions

Figura 2.12: Grano de adaptacion a nivel de espacio de trabajo en el sistema Ubidraw

macion causa la desaparicion tanto del editor de notas como del visor de video para adaptarseal reducido espacio del dispositivo destino (cf. Figura 2.13 tomada de [Demeure et al., 2005]).

Roomware usa un grano de adaptacion a nivel de pıxel cuando la IU es distribuida en lostres pizarrones electronicos de DynaWall (cf. Figura 2.14 tomada de [Prante et al., 2004]).


Mismo espacio de trabajo, menoscomponentes y diferentes dispositivos

Panel de control

Video

Editor de texto

a) Panel de control sobre una PC b) Panel de control sobre una Pocket PC

Figura 2.13: Grano de adaptacion a nivel de espacio de trabajo en el sistema CamNote

ConnecTables tambien se adapta a nivel de pıxel, porque permite a los usuarios tanto duplicarcomo tomar y soltar una imagen desde una tablet PC hacia otra cuando trabajan de maneracolaborativa (cf. Figura 2.15 tomada de [Tandler et al., 2001]). Otro sistema que se adapta anivel de pıxel es MindMap, el cual soporta la division de un mapa mental entre varios telefonoscelulares (cf. Figura 2.16 tomada de [Lucero et al., 2010]).

DynaWall: tres pizarrones electrónicos

Imagen dividida

Figura 2.14: Grano de adaptacion a nivel de pıxel en el sistema Roomware

Capıtulo 2 29

La imagen está siendo arrastradadesde un dispositivo a otro

Figura 2.15: Grano de adaptacion a nivel de pıxel en el sistema ConnecTables

El mapa mental está dividido entre dosteléfonos celulares

Figura 2.16: Grano de adaptacion a nivel de pıxel en el sistema MindMap

2.4 Granularidad de recuperacion del estado

La granularidad del estado de recuperacion [Vanderdonckt, et al., 2008] caracteriza el esfuerzode los usuarios que deben realizar para continuar su actividad despues de ocurrida la adaptacion.Existen diversos niveles de recuperacion, los cuales se mencionan a continuacion:

• Nivel de sesion: el usuario tiene que reiniciar su actividad desde el estado inicial delsistema, 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 inter-rumpida (a condicion de que la tarea es realizable en la IU);

• Nivel de accion fısica: el usuario puede continuar la tarea actual en el punto exactodonde la interrumpio (a condicion de que la tarea es realizable en la nueva version de laIU).


El sitio Web de Sedan-Bouillon soporta una recuperacion de estado a nivel de tarea porquesolo se pierde la tarea actual del usuario, e.g., si ocurre la redistribucion de la IU mientras elusuario esta llenando una forma, el tendra que comenzar nuevamente a llenarla (cf. Figura 2.17tomada de [Balme et al., 2005]), pero los resultados de las tareas previas no se veran afectados.Por otro lado, CamNote [Coutaz and Calvary, 2008] soporta la recuperacion a nivel de accionfısica, ya que conserva la diapositiva actual cuando el panel de control migra desde la PC ala PDA. El sistema MindMap [Lucero et al., 2010] soporta una recuperacion a nivel de accionfısica porque al unir o separar los telefonos celulares, el mapa mental se conserva sin cambios,e.g., suponga que en un arreglo de tres telefonos 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 estosdispositivos, el mapa mental sera escalado hasta desplegarse por completo en la pantalla dedicho telefono; ademas, el mapa continua mostrandose sin alteracion alguna en los otros dosdispositivos (cf. Figura 2.18.b tomada de un video3). El resto de los sistemas no proveensuficiente informacion para inferir el estado de recuperacion que implementan.

Perdida de información

anglais

restaurants

x

a) Antes de la adaptación (PC) b) Después de la adaptación (PC y PDA)

Figura 2.17: Grano de recuperacion 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 estatico o dinamico. Un despliegue estatico significa quela adaptacion de la IU se realiza cuando el sistema es lanzado en ejecucion. En este tipo dedespliegue no puede efectuarse remodelacion ni redistribucion de la IU, e.g., el sistema Pick andDrop [Rekimoto, 1997] realiza un despliegue estatico porque muestra una version predisenaday precalculada del sistema para una plataforma particular. Por el contrario, un despliegue

3Lucero, 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 ántesy despuésde la adaptación

Figura 2.18: Grano de recuperacion a nivel de accion fısica en el sistema MindMap

dinamico significa que la remodelacion y la redistribucion se pueden realizar en tiempo deejecucion [Vanderdonckt, et al., 2008].

Observe que un despliegue dinamico que soporta recuperacion a nivel de sesion es diferentede un despliegue estatico. En el primer caso, la remodelacion y/o la redistribucion ocurrendurante la ejecucion del sistema, provocando que el usuario regrese al estado de inicio. Enel caso del despliegue estatico se fuerza al usuario a salir de la sesion y a lanzar la versionapropiada del sistema.

Analizando el despliegue de la IU en los sistema de ejemplo, podemos decir que el sitio Webde Sedan-Bouillon provee un despliegue dinamico cuando redistribuye su espacio de trabajo. Dela misma manera, FlexClock remodela dinamicamente la ventana de interactores (e.g., alargael reloj analogico y centra el reloj digital) cuando el usuario redimensiona la ventana. Ubidrawtambien adapta su espacio de trabajo dinamicamente cuando el usuario lo redimensiona, e.g., siel espacio disponible es relativamente pequeno, solo los iconos relacionados con la tarea actualson accesibles.

Por otro lado, ConnecTables crea dinamicamente el espacio de trabajo compartido (vs. per-sonal) cuando dos usuarios acoplan (vs. desacoplar) sus tablets. De la misma manera queConnecTables, MindMap ofrece un despliegue dinamico al permitir a los colaboradores desple-gar a su gusto los mapas metales sobre varios telefonos celulares. Sin embargo, el sistema decontrol de calefaccion, CamNote y Roomware proveen despliegue estatico.


2.6 Cobertura del contexto de uso

El contexto de uso hace referencia a los espacios de informacion que sirven al procesode adaptacion cuando el contexto cambia. Un cambio en el contexto se define comola modificacion del valor de cualquier elemento del espacio de informacion contextual[Coutaz and Calvary, 2008]. Por contexto de uso se entiende la terna ≪usuario, plataforma,entorno≫ [Calvary et al., 2004, Calvary et al., 2001] donde:

• El usuario denota el arquetipo humano que tiene por objeto utilizar el sistema interactivo.

• La plataforma se refiere a los dispositivos de hardware y software disponibles para llevara cabo la interaccion del usuario con el sistema. La plataforma puede ser modelada enterminos de los recursos computacionales que determinan la forma en que se procesa, setransmite y se presenta la informacion, ası como la manera en que el usuario manipula lainformacion. Comunmente el tamano de la memoria, el ancho de banda de la red y losdispositivos de interaccion motivan la seleccion de un conjunto de modalidades de E/S y lacantidad de informacion disponible. Un cluster de dispositivos computacionales conecta-dos puede ser considerado como parte de la plataforma. Alternativamente, el cluster puedeser estatico o dinamico, i.e., los dispositivos computacionales pueden aparecer y desapare-cer automaticamente; la cardinalidad del cluster es un factor importante a considerar enlo referente a la escalabilidad y la usabilidad. Los dispositivos computacionales tambienestan caracterizados por los dispositivos de E/S que soportan [Vanderdonckt, et al., 2008],e.g., raton, teclado, pantalla tactil, stylus y voz.

• El entorno describe las condiciones fısicas y sociales donde tiene lugar la interaccion,e.g., los objetos, las personas y los eventos que son perifericos a la tarea que se esta desar-rollando, en un momento dado, pero que pueden tener un impacto en el comportamiento:a) del sistema, e.g., un entorno ruidoso puede eliminar la realimentacion por audio, y/o b)del usuario, e.g., su localizacion provee un contexto para la relevancia de la informacion.

Analizando los sistemas interactivos mono-usuarios se puede observar que el sitio Web deSedan-Bouillon pueden ser accedido desde una PC y una PDA (adaptacion a la plataforma).Ademas, este sitio identifica al usuario cuando esta trabajando desde diferentes dispositivos(adaptacion 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 (adaptacion a la plataforma),sino tambien adapta su IU al tamano de la ventana de acuerdo a la tarea actual (e.g.,el ultimo icono que fue seleccionado), la frecuencia de la tarea (e.g., la cantidad de clicssobre cada ıcono) y la preferencia del usuario por una tarea (e.g., la posicion del ıconoen las preferencias/necesidades de dicho usuario). La adaptacion a la tarea propuesta porUbidraw es parte del elemento “usuario” del contexto de uso (cf. Figura 2.20 tomada de[Vanderdonckt and Gonzalez-Calleros, 2008]).

Capıtulo 2 33

Dispositivo: PDA

a) Plataforma b) Usuario

Dispositivo: PC

Mismo usuario, Lionel,en dos dispositivos (0 y 1)

Figura 2.19: Adaptacion 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: Adaptacion a la plataforma y al usuario en el sistema Ubidraw

El sistema de control de calefaccion se adapta al hardware y al software (adaptacion a laplataforma) porque se ejecuta en aplicaciones Web o independientes; este sistema tambienpermite consultar la temperatura de los cuartos desde dispositivos diferentes, e.g., PDA, PC,telefono movil y reloj (cf. Figura 2.21 tomada de [Vanderdonckt and Gonzalez-Calleros, 2008]).En cambio, FlexClock solo puede ser ejecutado sobre una PC, pero adapta su IU al tamano dela ventana (simula la adaptacion a la plataforma).

CamNote se adapta a la plataforma debido a que puede ejecutar el panel de control sobre unaPDA. Cuando este componente es transferido a dicho dispositivo, se pierde el video en tiemporeal del usuario, ası como el editor de notas (cf. Figura 2.22 tomada de [Demeure et al., 2005]).


a) PC b) PDA c) Teléfono móvil

d) Reloj digital

Figura 2.21: Adaptacion a la plataforma en el sistema de control de calefaccion

a) PC b) Pocket PC

Figura 2.22: Adaptacion a la plataforma en el sistema CamNote

Por otro lado, Roomware esta habilitado para ejecutarse en tres diferentes dispositivos: Dy-naWall, InteracTable y CommChair (cf. Figura 2.23 tomada de [Prante et al., 2004]). Dosejemplos de plataforma diferentes a los anteriores son ConnecTables y MindMap. Para crear

Capıtulo 2 35

un espacio compartido, el primer sistema permite acoplar dos tablets (cf. Figura 2.24 tomadade [Tandler et al., 2001]) y el segundo facilita la formacion de un arreglo de dos o mas telefonoscelulares (cf. Figura 2.25 tomada de [Lucero et al., 2010]). Del lado derecho de la figura 2.25se muestran las posibles opciones para acoplar telefonos celulares en MindMap.

Dispositivo: PDA

a) Plataforma b) Usuario

Dispositivo: PC

Mismo usuario, Lionel,en dos dispositivos (0 y 1)

Figura 2.23: Adaptacion a la plataforma en el sistema Roomware

Detección física para crear un espacio compartido

Figura 2.24: Adaptacion a la plataforma en el sistema ConnecTables

En los sistemas analizados podemos observar que ninguno se adapta al entorno.


Dos o mas teléfonos celulares forman unespacio

Figura 2.25: Adaptacion a la plataforma en el sistema MindMap

2.7 Cobertura de espacio tecnologico

Un espacio tecnologico es un contexto de trabajo que incorpora un conjunto de conceptosasociados, 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 deontologıas (dataware). La mayorıa de las interfaces de usuario se ejecuta dentro de un soloespacio tecnologico, e.g., Tcl/Tk, swing, o HTML. Esta homogeneidad no es convenienteen las interfaces de usuario plasticas multi-modales, puesto que la redistribucion a diversosdispositivos computacionales puede requerir atravesar varios espacios tecnologicos, e.g., una IUen Java se debe transformar en una IU en WML 2.0 (Wireless Markup Language) al emigrar deuna PDA a un telefono movil WAP (Wireless Application Protocol) [Vanderdonckt, et al., 2008].

La cobertura del espacio tecnologico denota la capacidad de permitir la plasticidad de la IUen los espacios tecnologicos, los cuales se dividen de la siguiente manera:

• intra-Espacio tecnologico: corresponde a la IU que se ejecuta y se adapta a un soloespacio tecnologico;

• inter-Espacio tecnologico: se refiere a la IU que es transformada en un espacio tec-nologico diferente al actual;

• multi-Espacio tecnologico: concierne a las interfaces de usuario fuente y/o destinocompuestas de componentes expresados en espacios tecnologicos distintos.

Analizando el espacio tecnologico en los sistemas interactivos de ejemplo, pode-mos observar que el sitio Web Sedan-Bouillon —HTML/PHP [Balme et al., 2005]—,

Capıtulo 2 37

Ubidraw —Mozart/QTk/Oz [Vanderdonckt and Gonzalez-Calleros, 2008]—, FlexClock —Qtk[Grolaux et al,. 2002]— y MindMap —C++/Qt [Lucero et al., 2010]— permanecen dentro delmismo espacio tecnologico antes y despues de la adaptacion plastica (i.e., intra-TS). El restode los sistemas no ofrecen alguna informacion relacionada.

2.8 Meta-interfaz de usuario

El concepto de Meta-Interfaz de Usuario (Meta-IU) se define como la simplificacion de unentorno de desarrollo de usuario final. Una meta-IU completa debe permitir a los usuariosfinales programar (configurar y controlar) sus espacios interactivos, eliminar errores (evaluar),ademas de mantener y reutilizar programas. Dicha meta-IU determina las actividades quepueden ejecutarse en un espacio interactivo. La meta-IU considera diversos niveles, los cualesse presentan a continuacion [Vanderdonckt, et al., 2008]:

• plasticidad en la propia meta-IU: es un tema en exploracion, puesto que cada meta-IUse encuentra en un entorno cambiante;

• sin negociacion: permite que el usuario observe el proceso de adaptacion, pero no lepermite que intervenga; en este caso el sistema es autonomo;

• con negociacion: es recomendable cuando la meta-IU no puede tomar decisiones entrelas multiples formas de adaptacion, o cuando el usuario debe controlar por completo elresultado del proceso. En este tipo de meta-IU, se presenta el problema de equilibrar laautonomıa del sistema y la negociacion con el usuario;

• inexistente: se refiere la carencia de un entorno de desarrollo de usuario final.

La dimension recurrente de la meta-IU requiere definir una meta-IU autosuficiente, capaz deinstanciar la apropiada meta-IU cuando el sistema es lanzado en ejecucion.

Examinando los sistemas de prueba, el sitio Web Sedan-Bouillon [Balme et al., 2005] es elunico que provee una meta-IU con negociacion, porque el usuario coopera con el sistema parala redistribucion de los espacios de trabajo de la IU, i.e., el tıtulo de la pagina principal, elcontenido y el menu (cf. Figura 2.26 tomada de [Balme et al., 2005]). Finamente, CamNoteimplementa una meta-IU sin negociacion porque no permite que el usuario participe en elproceso de adaptacion, pero este sistema provee conciencia de adaptacion cuando el panel decontrol migra desde una PC a una PDA.


Meta-IU

Figura 2.26: Meta-IU con negociacion en el sitio Web de Sedan-Bouillon

2.9 Otras dimensiones

Otras dimensiones importantes corresponden a tipo de adaptacion, contexto mono-

entidad o multi-entidad y variables contextuales.

2.9.1 Tipo de adaptacion

El tipo de adaptacion comprende las siguientes maneras [Abowd et al., 1999]:

• presentacion de informacion y servicios al usuario: se refiere a una tecnica deinteraccion en donde se presenta una lista de objetos (e.g., impresoras) o lugares (e.g.,oficinas) cuyos elementos mas relevantes, de acuerdo al contexto de uso, son enfatizadoso mas faciles de escoger.

• ejecucion automatica de un servicio: en este caso no solo se presenta informacionrelevante sino que, dada la correcta combinacion de condiciones contextuales, se ejecutaautomaticamente una accion.

• informacion aumentada: algunos datos contextuales pueden ayudar a comprendermejor el entorno colaborativo en el que se trabaja, e.g., se puede identificar bajo quesituaciones las personas son mas activas.

El sistema de control de calefaccion, Ubidraw, FlexClock y Sedan-Bouillon se enfocan en lapresentacion de informacion y servicios. Dependiendo del tamano de la pantalla disponible, elsistema de control de calefaccion puede mostrar simultaneamente todos los cuartos o enfatizarel preferido por el usuario. Las herramientas de Ubidraw son reordenadas y resaltadas dependi-endo su frecuencia de uso. Por otro lado, FlexClock presenta la hora y/o la fecha, dependiendodel espacio disponible de la ventana. Cuando detecta dos dispositivos cercanos que acceden al

Capıtulo 2 39

sitio Web de Sedan-Bouillon, este sistema provee al usuario de una meta-IU para seleccionarlos componentes de la IU que pueden ser desplegados en cada dispositivo.

Varios de los sistemas de ejemplo se enfocan en ejecutar automaticamente un servicio, comoes el caso de CamNote, Roomware, MindMap y ConnecTables. CamNote permite la ejecucionautomatica de un servicio, ya que transfiere instantaneamente el panel de control hacia unapocket PC cuando detecta este dispositivo. Roomware esta centrado en la ejecucion automaticade servicios, pues es capaz de desplegar los espacios de trabajo privados y compartidos endispositivos personales y publicos, respectivamente.

ConnecTables tambien esta en la categorıa de ejecucion automatica de un servicio porqueeste convierte dos espacios de trabajo privados en uno compartido cuando dos tablets se acoplany viceversa. Al unir las tablets, el espacio de trabajo provee a los colaboradores con funcionesque permiten copiar y mover objetos desde una tablet hacia otra.

MindMap realiza la ejecucion automatica de dos servicios, los cuales corresponden a: 1)crear un espacio comun entre los telefonos y 2) escalar el mapa mental. El primer servicio seejecuta cuando los colaboradores unen dos o mas telefonos celulares por medio de gesticulacionesmanuales. El segundo servicio se refiere a dos tipos de escalamiento automatico de los mapasmentales. El primero concierne al escalamiento 1:1, el cual se realiza cuando dos o mas telefonosforman un arreglo. El otro tipo de escalamiento requiere que el mapa mental sea ajustado a lapantalla 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 situacion de una sola entidad que participa a lo largode la ejecucion del sistema, e.g., un usuario en particular puede cambiar varias veces el tamanode su ventana o expresar sus preferencias en un sistema, el cual es mono-entidad porque entodo momento atiende a un solo usuario. Mientras que los sistemas multi-entidad consideranla situacion de varias entidades de forma simultanea, e.g., los miembros de una organizacion[Olivares, 2011].

En la tabla 2.1 se muestra el analisis de los sistemas de ejemplo respecto al caracter mono ymulti -entidad. Dada la naturaleza cooperativa de ConnecTables, Roomware y MindMap, estossistemas son multi-entidades porque ellos consideran la presencia de multiples colaboradores yel estado de sus respectivos dispositivos (e.g., si ellos estan acoplados/desacoplados o si son deambito personal o publico).

Aun cuando Sedan-Bouillon solo soporta un usuario, este sitio Web corresponde a la categorıamulti-entidad porque su ejecucion puede ser compartida entre dos dispositivos cercanos cuandoes requerido. Por el contrario, Ubidraw es un sistema mono-entidad porque solo considera elestado de un solo usuario, el cual es expresado por la tarea actual y las preferencias, la frecuenciade uso de la herramienta y el tamano de la ventana. El sistema de control de calefaccion tambienes mono-entidad porque solo considera el estado de una plataforma de ejecucion a la vez, en


particular el tamano de la pantalla. Otro sistema mono-entidad es FlexClock, ya que solotoma en cuenta el tamano de la ventana disponible. Aun cuando el sistema CamNote es mono-usuario, este sistema es multi-entidad, puesto que puede reconocer la presencia de una PDA acierta distancia de una PC.

SistemaSoporte

multi-entidadEntidades

Sedan-Bouillon Sı Usuario y dispositivos

Control de calefaccion No Dispositivo

FlexClock No Tamano de la ventana

Ubidraw No Usuario

CamNote Sı Dispositivos

ConnecTables Sı Colaboradores y dispositivos

Roomware Sı Colaboradores y dispositivos

MindMap Sı Colaboradores y dispositivos

Tabla 2.1: Entidades contempladas por los sistemas analizados

2.9.3 Variables contextuales

Las variables contextuales se refieren a las variables relevantes que los sistemas consideranpara llevar a cabo la adaptacion [Ghiani et al., 2009].

La tabla 2.2 muestra las variables contextuales consideradas para la adaptacion de los propiossistemas. La mayorıa de los sistemas analizados usan variables fısicas, e.g., localizacion, tamanode la pantalla, proximidad, tipo de dispositivo, hora y fecha. Como la mayorıa de los sistemascooperativos, ConnecTables y Roomware soportan variables tıpicamente logicas, tales como lapresencia de los colaboradores en el espacio de trabajo compartido. En cambio, el sistemaUbiDraw toma en cuenta variables logicas mas sofisticadas, e.g., preferencias del usuario y lafrecuencia de uso de las herramientas.

En el caso de ConnecTables, los sensores detectan cuando dos de estos dispositivos estan

Capıtulo 2 41

acoplados. En cambio en MindMap, la adaptacion se lleva a acabo cuando se detecta los gestoscon las manos de los colaboradores para indicar la union de dispositivos, ası como cuando uncolaborador toma en su mano el dispositivo; dicha accion es registrada por el acelerometroincluido en el telefono.

Sistema Variables contextuales

Sedan-BouillonPreferencia de los usuarios y sensores de proximi-dad de los dispositivos

Control de calefaccion Tamano de la pantalla del dispositivo

FlexClock Tamano de la ventana

UbidrawTarea actual, tamano de la ventana y frecuenciade uso de las herramientas

CamNote Sensores de proximidad de los dispositivos

ConnecTablesPresencia de los colaboradores y sensores de proxi-midad de los dispositivos

RoomwarePresencia de los colaboradores y caracter publicoo personal de los dispositivos

MindMapGesticulaciones manuales y si un dispositivo formaparte o no de un arreglo

Tabla 2.2: Variables contextuales de los sistemas analizados

2.10 Conclusiones

Este capıtulo muestra una subarea del campo de Interaccion Humano-Computadora (IHM) lla-mada “Plasticidad de las Interfaces de Usuario”; dicha subarea es importante para el desarrollodel presente trabajo de investigacion porque propone considerar varios puntos relevantes paracrear una interfaz de usuario plastica en la etapa de diseno o en tiempo de ejecucion. Tambien,sistemas plasticos deben informar al usuario final acerca de la nueva adaptacion, ya sea que elusuario intervenga en el proceso de adaptacion o solo sea un observador pasivo.

Varios de los sistemas de ejemplo permiten expresar de manera visual la plasticidad, e.g.,


cambiar de modalidad grafica a textual cuando el dispositivo no lo soporte; redistribuir la IUentre dispositivos heterogeneos (e.g., pizarrones electronicos, PDA, PC y mesas) y adaptarse ala tarea del colaborador.

En los ejemplos presentados, se observa que la mayorıa de los sistemas se adaptan a laplataforma, principalmente estos sistemas se ejecutan sobre PDAs, tablets PC y computadorasportatiles; otras plataformas menos usadas son pizarrones electronicos, telefonos inteligentes orelojes. Muy pocos de estos sistemas consideran al usuario. La tendencia respecto al usuarioes considerar las tareas (frecuencia y preferencia) o reconocer cuando un mismo usuario estausando dos o mas dispositivos.

Capıtulo 3

Marcos de desarrollo de sistemas

plasticos

En este capıtulo se presentan siete marcos (frameworks) que fueron seleccionados por ser los masrepresentativos del tema de investigacion. Por cada marco se proporciona una breve descripcioncon la finalidad de resaltar sus caracterısticas mas importantes. Los dos primeros, RUIUM-O yCAMELEON-RT, facilitan el desarrollo de sistemas mono-usuario, mientras que los restantesestan enfocados en el desarrollo de sistemas colaborativos. A nuestro saber, el marco RUIUM-Oes el primero en considerar el contexto de uso y algunas otras dimensiones de la plasticidad,e.g., percutores y Meta-IU en la creacion de interfaces de usuario (cf. Seccion 3.1). El marcoCAMELEON-RT tambien considera el contexto de uso, ası como la redistribucion y la migracionde la interfaz de usuario (cf. Seccion 3.2).

El marco de PI es el primero en hacer converger aspectos de las interfaces de usuario plasticasde los sistemas mono-usuario y aspectos del trabajo colaborativo, e.g., conciencia de grupo(cf. Seccion 3.3). El marco PEC contempla el contexto de uso, la conciencia de grupo eimplıcitamente la Meta-IU (cf. Seccion 3.4). Mientras que los marcos ACCDP (cf. Seccion 3.5),RCCG (cf. Seccion 3.6) y GC (cf. Seccion 3.7) se enfocan solo en el contexto de uso, dejandode lado las demas dimensiones de la plasticidad, e.g., granularidad del estado de recuperacion.

En la seccion 3.8 del presente capıtulo se incluye un analisis comparativo de los marcosanalizados, con el fin de destacar sus ventajas y carencias. Finalmente, la seccion 3.9 presentalas conclusiones del presente capıtulo, las cuales exhiben las posibles tendencias de dichosmarcos.

43

44 Marcos de desarrollo de sistemas plasticos

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) pre-tende servir como referencia para ayudar a disenadores y desarrolladores a estructurar y de-sarrollar interfaces de usuario multi-objetivo en la etapa de diseno y en tiempo de ejecucion.Antes de empezar a describir dicho marco es importante mencionar que una interfaz de usuariomulti-objetivo es capaz de soportar multiples contextos de uso sin considerar la usabilidad[Calvary et al., 2003, Calvary et al., 2001].

3.1.1 Modelos ontologicos, arquetıpicos y observadores

El modelo general de RUIUM-O se compone de tres grandes partes: la primera corresponde alos modelos ontologicos, la segunda a los modelos arquetıpicos y la tercera a los modelosobservadores (cf. Figura 3.1).

Modelo Ontológico

Dominio

Adaptación

Contexto de Uso

Usuario (O3)

Tareas (O2)

Entorno (O5)

Configuración1

Evolución(I6)

Usuario(I3)

Transición(I7)

Plataforma(I4)

Entorno(I5)

Conceptos(I1)

Tareas(I2)

Modelo deConceptos y

Tareas(T1)

InterfazAbstracta

(T2)

InterfazConcreta

(T3)

Interfaz deUsuario FinalConfiguración

1 (T4)

S

C

E

Configuración2

Modelos Arquetípicos

(I6)

(I3)

(I7)

(I4)

(I5)

(I1)

(I2)

(T1)

(T2)

Infraestructura en tiempo de ejecución

(T3)

(T4)

S

C

E

S

C

E

ModelosObservadores

(O4)Plataforma

Evolución (O6)

Transición (O7)

Conceptos (O1)

Figura 3.1: Marco de Referencia Unificado para Interfaces de Usuario Multi-Objetivo

Los modelos ontologicos son meta-modelos independientes tanto del dominio como de lossistemas interactivos. Dichos modelos tienen como objetivo identificar las dimensiones clave

Capıtulo 3 45

para dar una solucion al problema en cuestion. Los modelos ontologicos estan representadospor 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 descripcion 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 cualquiercontexto de uso y puede ser representado mediante diagramas de clases UML. El modelode tareas (O2) describe las tareas que el usuario manipula en cualquier contexto deuso y es representado mediante una estructura ConcurTaskTree 1, en donde las hojascorresponden a las tareas de interaccion (e.g., leer y seleccionar), los nodos son tareasabstractas y los vertices representan tanto relaciones temporales como la logica de lastareas.

2. El modelo de contexto de uso se refiere a caracterizar el usuario, la plataforma y elentorno. 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 re-cursos cercanos, los cuales estan clasificados en dos categorıas: a) plataforma basica parareferirse tanto a recursos fısicos como logicos que funcionan como una unidad, cuyo estadopuede ser observado o modificado por un usuario humano y b) clusters compuestos de laplataforma basica que pueden ser homogeneos o heterogeneos. El modelo de entorno

(O5) identifica dimensiones genericas para describir el entorno cercano.

3. El modelo de adaptacion especıfica tanto la reaccion ante un cambio de contexto comoel camino para conmutar entre contextos. El modelo de adaptacion funciona a partirdel modelo de evolucion y de transicion. El modelo de evolucion (O6) indica alos sistemas interactivos cuando deben adaptarse a cambios, mientra que el modelo de

transicion (O7) tiene como objetivo suavizar discontinuidades entre dichos cambios decontexto.

Los modelos arquetıpicos son modelos predecibles que sirven como entrada en el proceso dediseno. Dichos modelos combinan una serie de operaciones para generar un sistema interactivosensible al contexto, mediante la transformacion de modelos iniciales en modelos transitorios.

Los modelos iniciales son descritos por los desarrolladores, mientras que los transitorios soninferidos por los desarrolladores y/o el sistema a traves del proceso de desarrollo. Los modelosiniciales y transitorios estan representados respectivamente por las letras I y T en el marcoRUIUM-O (cf. Figura 3.1). Un modelo transitorio contiene tanto el modelo de tareas y

conceptos (T1), como las interfaces de usuario abstractas (T2) y concretas (T3) nece-sarias para la produccion de la interfaz de usuario final (T4) [Calvary et al., 2003].

La interfaz de usuario abstracta (IU abstracta) es una expresion canonica de los con-ceptos y funciones, e.g., en la herramienta ARTStudio [Calvary et al., 2001] la interfaz deusuario es modelada como un conjunto de espacios de trabajos isomorfos al modelo de las

1Es una notacion grafica que sirve para describir el modelo de tareas [Paterno and Mancini, 1997].


Tarea. Los espacios de trabajo, e.g., la temperatura de los cuartos de una casa, son inferi-dos a partir de las relaciones de las tareas que fueron previamente expresadas en los modelosde conceptos (I1) y de tareas (I2). Los espacios anteriores, los cuartos de una casa sonrepresentaciones de una tarea abstracta, e.g., actualizar la temperatura.

La interfaz de usuario concreta (IU concreta) convierte una IU abstracta en una ex-presion dependiente del interactor. Por ejemplo, la herramienta ARTStudio convierte el espaciode trabajo principal en una ventana, mientras que los demas espacios pueden ser ventanas ocanvas. La IU concreta “se ejecuta dentro del entorno de desarrollo”, e.g., la interfaz de usuarioconcreta generada por ARTStudio se ejecuta dentro de la misma herramienta.

Los modelos transitorios son producidos por dos tipos de operaciones: 1) transformacionvertical y 2) transformacion horizontal. La transformacion vertical se refiere a procesar losmodelos transitorios (tareas y conceptos, IU abstractas y concretas) de abajo hacia ar-riba o viceversa. Dentro de esta transformacion se encuentra la reification, la cual cubre elproceso de derivacion desde el modelo de tareas hasta la interfaz de usuario final (T4).La transformacion horizontal corresponde a la translacion entre modelos del mismo nivel, endonde la “translacion” significa una operacion que transforma la descripcion de un objetivoparticular en otra descripcion de la misma clase, pero con diferente objetivo. Una operacioncruzada significa tanto trasladarse a otro contexto de uso como cambiar el nivel de reification.Todas las operaciones de transformacion pueden ser ejecutadas de manera automatica o man-ual. La interfaz de usuario final (IU final) es generada a partir de la IU concreta y esexpresada en codigo fuente, e.g., Java o HTML. Dicha IU final soporta adaptacion dinamicamulti-objetivo.

El modelo de evolucion (I6) sugiere estructurar la adaptacion multi-objetivo en tres eta-pas: 1) reconocimiento de la situacion, 2) procesamiento de la reaccion y 3) ejecucion de lareaccion. El reconocimiento de la situacion registra el contexto (e.g., la temperatura actuales de 22◦C), detecta cambios contextuales (e.g., la temperatura ha incrementado de 18◦C a22◦C) y finalmente identifica cambios de contexto (e.g., cambiar la temperatura “regular” por“confortable”). El procesamiento de la reaccion involucra tanto la identificacion de las solu-ciones candidatas como la seleccion de una solucion; esta reaccion puede involucrar cambiosde plataforma (e.g., cambiar de una PC a una PDA), cambios de entorno (e.g., encender laluz porque el cuarto esta muy obscuro) o cambiar de codigo ejecutable debido a que el codigoactual no soporta el cambio de contexto. Finalmente, la ejecucion de la reaccion involucra larealizacion de las siguientes acciones:

• prologo: se encarga de preparar la reaccion al completar, suspender o abortar la tareaactual;

• reaccion: implica cambiar hacia la nueva version (e.g., mostrar una nueva secuencia dedialogo o ejecutar una tarea especıfica);

• epılogo: se encarga de finalizar la reaccion al restaurar el contexto de ejecucion (e.g.,restablecer la tarea interrumpida).

Capıtulo 3 47

Los modelos observadores conducen la adaptacion en tiempo de ejecucion. Tanto el modeloontologicos Oj como su modelo homologo arquetıpicos Ij pueden ser referenciados por lainfraestructura en tiempo de ejecucion o por la IU final (ver Figura 3.1), los cuales estanencargados de la etapa de adaptacion (reconocimiento de la adaptacion, calculo y ejecucion dela reaccion).

3.1.2 Implementacion

Bajo el marco RUIUM-O no se creo ninguna herramienta o caso de estudio, pero los autoresde este marco seleccionaron algunas herramientas dedicadas al diseno de interfaces de usuariopara dar una idea de como 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 modelosformales. El caso de estudio que se reporta con dicha herramienta es un simulador de controlde trafico aereo 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 deejecucion. Dicha herramienta considera varias plataformas, ası como diferentes modalidades.

Finalmente, TERESA ofrece tanto una metodologıa para disenar interfaces de usuario mul-timodales sobre varias plataformas, como una herramienta que sigue dicha metodologıa. Lasmodalidades que soporta esta herramienta son grafica, vocal, gestos, etc.

Las tres herramientas analizadas agregan tanto un modelo de presentacion como un modelode dialogo, los cuales no son considerados en el marco analizado. El modelo de presentacionespecifica aspectos de la presentacion de la IU en terminos abstractos, ası como la invocacionde ellos, e.g., en un metodo se especifica como presentar graficamente las propiedades de unavion. El modelo de dialogo contiene la descripcion del comportamiento y la interaccion delas clases.

Existe cierta coincidencia entre los modelos del marco RUIUM-O y las herramientas anali-zadas, e.g., dichas herramientas cubren completamente los modelos ontologicos, 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 dela IU final. Como se menciono en la seccion 3.1.1, los modelos Iniciales corresponden a lossiguientes modelos: conceptos (I1), tareas (I2), usuario (I3), plataforma (I4), entorno (I5),evolucion (I6) y transicion (I7).

Del conjunto de modelos Iniciales, PetShop solo utiliza el modelo de conceptos (I1) ya queel desarrollador realiza una descripcion de lo que debe hacer el sistema, e.g., cada avion queforma parte del simulador puede desplegar un menu al dar clic derecho sobre este. PetShopno solo agrega los modelos de presentacion y de dialogo, sino tambien incluye el modelode aplicacion. Este modelo sirve para dar acceso a los metodos de las clases contenidas en


Modelos Generacion

Herramienta ontologicos arquetıpicosManual/Auto-matica

Diseno/Ejecucion

PetShop

O1-O7, Inte-ractoresa

I1, T8 tareasb, T9-T11,aplicaciona, presentacion ydialogo Ambos

Etapa dediseno

Contexto de uso: no aplica

SEESCOA

O1-O7 Inte-ractoresa

I4, T2-T4, presentaciona,dialogo y Dispositivos Ambos

Tiempo deejecucion

Contexto de uso: plataforma

TERESA

O1-O7 Inte-ractoresa

I1, I2, I4, T1-T4, pre-sentaciona y dialogo Ambos

Etapa dediseno

Contexto de uso: plataforma

Tabla 3.1: Herramientas de ejemplo para el marco RUIUM-O

aEl marco no considera este componente, pero la herramienta sıbEl marco si lo considera, pero la herramienta no

el modelo de conceptos, e.g., la clase PlaneManager simula un radar para administrar losaviones y la clase Plane permite crear aviones dentro del radar. El modelo de presentacion

que implementa PetShop permite enriquecer la interfaz de usuario mediante tres aspectos: a) lainterpretacion de los metodos necesarios para mostrar informacion en la pantalla, e.g., show()o hide(), b) la activacion relaciona los metodos con los eventos, e.g., despliegue de un menumediante un clic derecho sobre un avion y c) una funcion que se encarga de responder a losmetodos invocados.

De los modelos Iniciales propuestos por el marco RUIUM-O, SEESCOA retoma el modelode plataforma (I4), mientras que TERESA se interesa en los modelos de conceptos (I1), detareas (I2) y de plataforma (I4). La metodologıa de TERESA recomienda empezar por hacerdescripciones de las tareas, e.g., “apagar la luz”.

Los modelos transitorios corresponden a los modelos de tareas y de conceptos (T1), IUabstracta (T2) e IU concreta (T3). En el caso de PetShop, este solo implementa el modelode conceptos, el cual es generado a partir de los modelos de conceptos (I1) y de aplicacion.La IU abstracta es generada mediante los modelos de presentacion y de dialogo.

Capıtulo 3 49

SEESCOA incluye solo las interfaces de usuario (T2-T4) en la etapa de modelos transitorios;la IU abstracta (T2) es generada a partir de los modelos de presentacion, de dialogo, deplataforma y de Dispositivos. En esta herramienta no se incluye el modelo de tareas debidoa que las tareas de un usuario no cambian durante el proceso de adaptacion.

TERESA genera el modelo de conceptos y de tareas (T1) mediante los modelos deconceptos (I1) y tareas (I1) pertenecientes a los modelos Iniciales. La IU abstracta (T2) esgenerada a partir de los modelos de presentacion, de dialogo y de plataforma, e.g., para latarea de “apagar la luz”, la seleccion del objeto de interaccion (comando de voz o interacciongrafica) se lleva a cabo la IU abstracta (T2), mientras que la seleccion tanto de la plataformacomo de la modalidad, se lleva a cabo en la IU concreta (T3).

La generacion de la interfaz de usuario (abstracta, concreta o final) del marco RUIUM-O puede ser automatica (sin que intervenga un humano), manual (el humano realiza dichaactividad) o semi-automatica (generada tanto por la herramienta como por el humano). Lastres herramienta presentadas permiten la intervencion tanto del sistema como del humano enla creacion de algunas de las interfaces de usuario, en especıfico en la IU abstracta (T2).Tanto SEESCOA como TERESA ofrecen diferentes vistas de la misma IU, permitiendo que eldesarrollador elija la mas apropiada.

Dos de las herramientas analizadas, PetShop y TERESA, proponen analizar y estructurar laIU final (T4) en la etapa de diseno. Por otro lado, SEESCOA es la unica herramienta queimplementa la generacion de interfaces de usuario en tiempo de ejecucion.

Es importante destacar que tanto SEESCOA como TERESA consideran la adaptacion delcontexto de uso a nivel de plataforma en la etapa de diseno, ademas de considerar la multi-modalidad.

3.2 CAMELEON-RT

CAMELEON-RT es un modulo arquitectural de referencia conceptual que soporta la distri-bucion y la migracion de la interfaz de usuario en grupos dinamicos heterogeneos, los cuales serefieren a conjuntos de computadoras que soportan la incorporacion y el retiro de dispositivossin afectar a la tarea en curso [Balme et al., 2004].

3.2.1 Capas de sistemas interactivos, DMP y plataforma

CAMELEON-RT esta estructurado en tres niveles de abstraccion (cf. Figura 3.2): en la partesuperior se encuentra la capa de sistemas interactivos; en la parte media se observa el nucleode la arquitectura, la cual contiene el middleware Distribucion-Migracion-Plasticidad

(middleware DMP) y, finalmente, en la parte inferior esta la capa de plataforma.


Hardware (sensores, actua-dores, superficies, ...)

Sistema operativo

Sistema interactivo

Infr

aest

ruct

ura

de

conte

xto

Herramientasde

interacción

Administradorde plataforma

Sintetizadorde situación

Observador de sis-tema interactivo

Meta- IU

Observador deplataforma

Observador delugar físico

Observador deusuario

Motor deevolución

Administra-dor de

componente

SO 1 SO 2 SO 3 SO 4 SO 5

Configurador

Herramientaspara abstracción,

traslación yconcretización

Espacio dealmacenami-

entoIdentificador de situación

Administrador de adaptación-abierta

Productor deadaptación

Capa de sistemas interactivos

Capa DMP

Capa plataforma

Figura 3.2: Estructura del modelo arquitectural de referencia CAMELEON-RT

La capa de plataforma incluye tanto el hardware como el sistema operativo. El hardwarese refiere a una variedad de entidades fısicas, e.g., superficies e instrumentos, capacidad deprocesamiento y servicios de comunicacion, ası como sensores y actuadores.

La capa de sistemas interactivos incluye los sistemas interactivos (e.g., una aplicacionCamNote 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 elespacio interactivo y proporciona a los usuarios los medios para configurar, controlar y evaluarel estado de dicho espacio.

La capa middleware DMP satisface tres requisitos: el modelado del espacio fısico, losgrupos dinamicos heterogeneos y la adaptacion de la interfaz de usuario (cuando ocurre laredistribucion o la migracion). A cada requisito mencionado le corresponde un servicio dela capa DMP: una infraestructura de contexto, un administrador de plataforma,herramientas de interaccion y un administrador de adaptacion-abierta (se dice queuna interfaz de usuario es adaptativa-abierta si provee un mecanismo de administracion).

Capıtulo 3 51

La infraestructura de contexto permite al espacio interactivo crear y mantener un mode-lo del lugar fısico. Esta infraestructura genera informacion contextual en el apropiado nivel deabstraccion, a partir de los sensores de datos y de los eventos del sistema operativo.

Tanto el administrador de plataforma como las herramientas de interaccion tienen elmismo papel funcional del entorno de X-Windows 2, con la diferencia de que amplıan los gruposheterogeneos dinamicos. La ampliacion de dichos grupos incluye: a) apoyar el descubrimientode dispositivos, b) ocultar la heterogeneidad de los sistemas operativos y del hardware y c)apoyar la redistribucion y la migracion de las interfaces de usuario.

El administrador de adaptacion-abierta incluye observadores que proporcionan infor-macion contextual apropiada a un sintetizador de situacion, cuyo rol es informar al motorde evolucion sobre la aparicion de una nueva situacion que puede requerir una adaptacionabierta. En caso de que se requiera tal adaptacion, el motor de evolucion utiliza los compo-nentes recuperados del espacio de almacenamiento, ademas de un configurador para pro-ducir una nueva interfaz de usuario.

Los observadores sirven como puertas entre el entorno y el sintetizador de situacion.El observador de plataforma reune informacion relacionada con los dispositivos (e.g., lle-gada y salida de una PDA o acoplamiento de dos superficies) mediante la suscripcion de loscomponentes del contexto para conocer la evolucion de la plataforma.

El observador de lugar fısico mantiene un modelo del lugar fısico (e.g., ubicacion de unusuario en la sala R o en la calle S). Por otro lado, el observador de usuario se enfoca enlos usuarios, e.g., su perfil o su posicion relativa a una superficie vertical. El observador de

sistemas interactivos se suscribe a informacion relevante para la plastificacion de sistemasinteractivos.

El sintetizador de situacion recopila informacion de la situacion actual, la cual es pro-porcionada por los observadores. Una situacion se define por un conjunto de observadores quesatisface un conjunto de predicados.

El motor de evolucion genera una reaccion en respuesta a una nueva situacion mediante ungrafo de situaciones. La reaccion puede ser una combinacion de las especificaciones indicadaspor los desarrolladores y/o los usuarios (mediante una Meta-IU) o adquirida por dicho motor

de evolucion.

El configurador ejecuta la reaccion expresada por los desarrolladores; si se necesitan nuevos

2X-Windows esta enfocada en dotar a los sistemas UNIX de interfaces de usuario, dicho planteamientosurgio alrededor del ano 1984. Este sistema permitıa a las aplicaciones un despliegue mediante la red sobredispositivos independientes, haciendo transparente la red. X-Windows tiene tres principales componentes: 1) eladministrador de ventanas se encarga de controlar el tamano y los atributos de las ventanas y de remplazarla ventana de una aplicacion, 2) el administrador de entradas implementa el resto de la interfaz, i.e., estecontrola que aplicacion ve la entrada de cierto dispositivo y 3) el sistema windows base se encarga de construiry pasar los parametros necesarios a las aplicaciones, al administrador de ventanas y al administrador de entradas[Gettys and Packard].


componentes, estos son recuperados del espacio de almacenamiento por el administradorde componentes.


Por medio de CAMELEON-RT se crearon dos casos de estudio, los cuales son CamNote (porCAMELEON Note) y I-AM (Interaction Abstract Machine). Como se menciono en el capıtulo2, el primero es un visualizador de diapositivas que se ejecuta en plataformas heterogeneasdinamicas, pocket PC y PC. La aplicacion CamNote puede ejecutarse por completo en unaPC o bien puede dividirse entre los dispositivos mencionados. I-AM es un administrador deplataforma que en esencia es similar a X-Windows, pero soporta grupos dinamicos heterogeneos.A continuacion se describen los componentes de las capas de CAMELEON-RT que se utilizaronestos 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 cualpermite al usuario evaluar la migracion y el proceso de adaptacion del panel de control;

Como se menciono en la seccion 3.2.1, la capa middleware DMP esta formada de tres gruposde componentes: dentro de esta capa se tienen tres grandes grupos: 1) la infraestructura

de contexto, 2) el administrador de plataforma y un conjunto de herramientas de

interaccion, y 3) un administrador de adaptacion-abierta. Respecto a esta capa, I-AM solo implementa el segundo grupo de componentes, ya que posee una infraestructura paradescubrir cambios en la plataforma, oculta la heterogeneidad del hardware (PC y PDA) y so-porta la migracion de la interfaz de usuario. Por otro lado, CamNote implementa los siguientescomponentes del tercer grupo: el motor de evolucion mediante reglas determinadas por eldesarrollador y el configurador de situacion a traves de una tecnica de recuperacion de datos.Ademas, CamNote crea una nueva situacion (a partir del sintetizador de situacion) enrespuesta a la llegada o salida de una pocket PC.

3.3 Marco de Plasticidad Implıcita

El marco de Plasticidad Implıcita (PI) [Sendın and Collazos, 2006] tienen como objetivo incor-porar plasticidad y conciencia de grupo en sistemas colaborativos, a partir del desarrollo deuna plantilla generica y adaptable denominada IPE (Implicit Plasticity Engine). El conceptode “plasticidad implıcita” se refiere a la adaptacion dinamica de la interfaz de usuario de unsistema colaborativo cuando un usuario cambia a un nuevo contexto de uso, e.g., cambios enel nivel de la luz de dıa, en el ancho de banda de la red o en la localizacion del usuario. Loscambios en la interfaz de usuario se pueden resolver mediante un reajuste automatico en el lado

Capıtulo 3 53

del cliente, sin requerir ninguna peticion dirigida al servidor [Sendın and Lores, 2004].

La plantilla IPE ofrece un mecanismo en tiempo de ejecucion con la capacidad de: 1)detectar el contexto y 2) adaptar la interfaz de usuario a cambios contextuales. De esta forma,IPE provee una adaptacion pro-activa del lado del cliente.

El objetivo del marco es proporcionar una retro-alimentacion sin discontinuidades duranteel proceso de adaptacion plastica, manteniendo ambos lados (cliente y servidor) en continuaactualizacion. Bajo este enfoque, el cliente solo recurre al servidor cuando necesita reconfiguraruna interfaz de usuario no resuelta localmente por IPE. Para realizar dicha reconfiguracion,el cliente envıa al servidor los cambios contextuales que requieren adaptaciones a la nuevasituacion.

La platilla IPE se divide en tres capas:

1. la capa logica contiene el nucleo funcional de la aplicacion;

2. la capa de aspectos es una capa intermedia responsable de aplicar la adaptacion sobreel nucleo funcional segun el modelo contextual (capa de conciencia de contexto).Desde el punto de vista de la colaboracion, la capa de aspectos debe comunicar eventosy acciones para mejorar las actividades de grupales;

3. la capa de conciencia de contexto permite controlar y modelar condiciones en tiemporeal (modelo contextual); en el caso de los sistemas colaborativos, esta capa es responsablede administrar toda la informacion relacionada con la comunicacion y la coordinacion queafectan al grupo.

Hasta el dıa de la publicacion del artıculo, los autores reportan que estan desarrollando elsoporte colaborativo del lado del servidor, por lo tanto no existe ninguna implementacion deeste marco.

3.4 Marco de Plasticidad Explicita Colaborativa

Sendin et al. proponen un marco conceptual llamado Plasticidad Explicita Colaborativa (PEC).La plasticidad explicita [Sendın and Lores, 2004] es la capacidad de generar automaticamenteuna IU especıfica para un contexto de uso, empezando de una especificacion abstracta. Paralogar la generacion automatica de dichas interfaces se requiere de una maquina EPE (ExplicityPlasticity Engine), en la etapa de diseno [Sendın and Collazos, 2006].

Este marco se ubica del lado del servidor para llevar a cabo las adaptaciones necesariascuando el cliente haya iniciado una sesion o solicite una nueva adaptacion.


Este marco aborda tres puntos: 1) conciencia de grupo como un parametro de la plasticidad,2) integracion de un mecanismo de conciencia tanto del lado del cliente como del lado delservidor y 3) integracion de una vista general del conocimiento compartido. Este ultimo serefiere a todos los aspectos del trabajo colaborativo que pueden ser usados en el desarrollo deuna actividad grupal [Sendin et al., 2008].

3.4.1 Fases ARP, CRP, IMP y PIM

EL marco PEC se divide en cuatro fases: 1) Abstract Rendering Process (ARP), 2) ConcreteRendering Process (CRP), 3) Implementation (IMP) y Preparation of the Initial Models (PIM).La fase PIM contiene los repositorios necesarios para llevar a cabo la adaptacion, e.g., Dia-logueM, TaskM, DominioM y SpacialM. La fase ARP genera la Interfaz de Usuario Abstracta(concrete UI) usando los siguientes modelos: TaskM, DominioM, SpacialM, UserM, DialogueMy GroupM. La fase CRP obtiene la Interfaz de Usuario Concreta (IU concreta) a partir de laabstract UI; esta fase selecciona los componentes concretos de la IU que mejor representanla funcionalidad descrita por los componentes abstractos. Finalmente, la fase IMP genera laInterfaz de Usuario Final (IU final) a partir de la IU concreta y regresa la IU final como codigoejecutable o interpretable. Las fases ARP, CRP e IMP se componen de varios modelos, los masrepresentativos se mencionan a continuacion (cf. Figura 3.3):

• TaskM: es una representacion estructurada de las tareas que un usuario puede llevar acabo mediante una interfaz de usuario;

• DomainM: denota los objetos relacionados con la tarea de un usuario;

• UsuarioM: representa las caracterısticas y los aspectos relacionados con un usuario, talescomo el nivel de conocimiento, preferencias, objetivos, situacion, necesidades, etc.;

• DialogueM: se utiliza para describir la conversacion entre una persona y una computadora.El modelo de dialogo permite establecer el estilo de navegacion;

• SpatialM: es una descripcion detallada del mundo real que proporciona conciencia deubicacion;

• PlatformM: e refiere a una expresion explıcita de la plataforma de interaccion en terminosde recursos fısicos y caracterısticas de software (e.g., sistema operativo, version de lamaquina virtual de Java y configuracion);

• EnvironmentalM: considera el tiempo (e.g., hora y dıa de la semana) y las condicionesambientales (e.g., luz del dıa, nivel de ruido ambiental y condiciones meteorologicas) queson especıficos para cada dominio de aplicacion y que influyen en la adaptacion;

Capıtulo 3 55

Figura 3.3: Marco conceptual de Plasticidad Explicita Colaborativa

• GroupM: es una representacion del conocimiento compartido; en este modelo se considerauna memoria de grupo, la cual se puede conceptualizar como una coleccion de percepcionesindividuales (conciencia de grupo).

El marco PEC se compone de los modelos previamente mencionados y de los niveles deabstraccion enlistados a continuacion [Calvary et al., 2003, Sendin et al., 2008]:

1. abstract IU : es la interpretacion de los conceptos de domino y funciones, los cuales sonindependientes de los interactores. Esta interfaz de usuario es generada en la fase ARP;


2. concrete IU: hace explıcita la interfaz de usuario final, aunque esta solo se ejecute dentrodel entorno de desarrollo en el que fue creada, e.g., para visualizar una interfaz de usuarioque no es ejecutable. La fase CRP obtiene esta interfaz de usuario a partir de la abstract

UI;

3. final IU: es generada a partir de la concrete IU), la cual es expresada en codigo fuente,e.g., Java y HTML. Esta interfaz de usuario puede ser interpretada o compilada como unainterfaz de usuario pre-calculada, ademas de que es lanzada en ejecucion en el entorno dedesarrollo en donde fue creada. La fase que se encarga de generar la final IU es IMP (cf.Figura 3.3) ya que transforma el aspecto visual y dinamico de la concrete UI en codigoejecutable.

El marco PEC no solamente utiliza modelos y niveles de abstraccion, sino tambien empleacomponentes, e.g., el modelo repositorio permite compartir conceptos, en tanto que el modelode transformacion describe la conversion de la abstract UI a la concrete UI . Asimismo,este marco maneja reglas de colaboracion para informar cuando el servidor recibe una solicitudde un miembro del grupo.


Una implementacion del marco PEC es la herramienta AB-UIED que soporta casi todos loscomponentes del marco, excepto los relacionados con el soporte de la colaboracion (e.g., modelode grupo) [Sendin et al., 2008]. Algunos de los modelos implementados en AB-UIED son lossiguientes:

• TaskM: usa tres diferentes notaciones, tales como diagrama de estado, modelo CTT,ademas de una herramienta de interaccion abstracta;

• concrete UI: usa UMLi (Unified Modeling Language for Interactive Applications);

• concreta UI : usa UsiXML (User Interface eXtensible Markup Language);

• final UI : es realizada por un traductor;

• Usability criteria: describe el peso y la importancia de cada criterio de usabilidad.

3.5 Marco para la Adaptacion de la Conciencia de Con-

texto en Despliegues Publicos

El proposito de este marco [Cardoso and Jose, 2009] es orientar a los disenadores en la creacionde despliegues publicos que ofrezcan la informacion correcta en el momento adecuado. Dentro

Capıtulo 3 57

de las organizaciones, los despliegues publicos se han utilizado para facilitar las tareas, lasincronizacion grupal, el trabajo cooperativo, la construccion de una memoria individual ygrupal, etc. [Churchill et al., 2004].

Este marco pretende lograr su objetivo mediante la relacion de tres fases: huellas

digitales, Datos y Adaptacion. La adaptacion contextual comienza por la fase huellas

digitales (cf. componentes Hd1.1-Hd4 de la Figura 3.4), la cual se puede expresar como unconjunto de datos en la fase de Datos (cf. componentes D1-D4 de la Figura 3.4) que sirven pararealizar la adaptacion en la fase de Adaptacion (cf. componentes A1-A4 de la Figura 3.4). Enparticular, los componentes A1-A4 del proceso de adaptacion son solo sugerencias que puedenser remplazadas por los disenadores.

Huellas digitales Datos Adaptación

Patrón depresencia

(D1)

Palabras claves(D3)

Popularidad delos elementos

(D4)

Patrón depresenciaindividual

(D2)

Adaptación dependiendo ciertascaracterísticas, e.g., género y edad.

(A1)

Adaptación individual, e.g., nomostrar el contenido previamentevisto por el usuario.

(A2)

Adaptación combinando la presenciaindividual y palabras claves, e.g.,mostrar deportes cuando la mayoríade usuarios estén interesados.

(A3)

Adaptación al mostrar automá-ticamente contenido de interés encierto lugar.

(A4)

Caracterizaciónde la presencia

(Hd1.1)

Identificación dela presencia

(Hd1.2)

Enriquecimientode la presencia

(H2)

Sugerencia decontenido

(Hd3)

Detección dereacción(Hd4)

Figura 3.4: Marco para la Adaptacion de la Conciencia de Contexto en Despliegues Publicos

Particularmente, la fase huellas digitales hace referencia al historial generado de las in-teracciones implıcitas o explicitas de un usuario con un despliegue publico. Dichas interaccionespueden ser de diferentes tipos, e.g., palabras claves, presencia, contenido, retro-alimentacion decontenido y perfiles personales. Cordoso y Jose se enfocan en los siguientes cuatro componentesde la fase de huellas digitales (Hd): presencia (Hd1.1 y Hd1.2), presencia enriquecida

(Hd2), sugerencia de contenido (Hd3) y deteccion de reaccion (Hd4).

Tanto la caracterizacion de presencia (Hd1.1) como la Identificacion de presencia

(Hd1.2) pertenecen a la huella digital de presencia. En este marco, la presencia se refiere a lahabilidad de colectar informacion 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 yel genero de dichas personas, periodos de alta y baja actividad en el lugar y la presencia depersonas con ciertas caracterısticas.

El mecanismo de interaccion que puede usarse para generar el componente Hd1.1 es el de


deteccion facial. Una vez obtenida la caracterizacion, se puede aplicar algun Patron de presencia(D1) para realizar algun tipo de Adaptacion A1, e.g., suponiendo que la audiencia se caracterizapor genero, se puede desplegar informacion relevante para mujeres cuando la mayorıa de laaudiencia sea del genero femenino.

La Identificacion de presencia (Hd1.2) es la habilidad de detectar quien esta presente,ya que esto permite asignar una unica identidad. El enriquecimiento de la presencia

(Hd2) se refiere a la habilidad de obtener informacion acerca de los intereses, preferencias yactividades de las personas cercanas a un despliegue. Los posibles mecanismos de interaccionque generan tanto la identificacion como la presencia son los de deteccion por Bluetooth o RFID(Identificacion por Radio Frecuencia), con la diferencia de que el componente Hd2 requiere queambas detecciones proporcionen, adicionalmente el perfil del usuario, en cambio el componenteHd1.2 no requiere dicho perfil. Otra forma de generar el componente Hd2 es mediante software,e.g., obtener dicha informacion de paginas personales o de un conjunto de intereses previamenteestablecidos en algun sitio de Internet.

Una vez obtenida la identificacion de la presencia se puede implementar el patron individualde presencia (D2), el cual permite a los sistemas de despliegue minimizar la repeticion delcontenido visto por cada usuario o identificar en que periodos de tiempo se encuentra la mismapersona, ası como establecer una correlacion entre diferentes personas o grupos (cf. componentede adaptacion A2).

En este marco, la sugerencia de contenido (Hd3) permite que los usuarios intervengan demanera implıcita, ya que ellos clasifican el contenido dependiendo del lugar. Dicho contenidolo provee el usuario de manera directa al enviarlo (e.g, imagenes o audio) o de manera indirectamediante un URL.

La deteccion de reaccion (Hd4) se refiere a la habilidad de detectar la reaccion de losusuarios hacia cualquier accion sugerida por un despliegue. Los mecanismos de interaccionpara los componentes Hd3 y Hd4 pueden ser el correo electronico, el servicio de mensajescortos (SMS por su siglas en ingles) y la tecnologıa Bluetooth. Ambos componentes (Hd3 yHd4) utilizan los mismos mecanismos, solo que el primero los utiliza para proveer el contenidoy el segundo para enviar comandos de texto. Otra diferencia radica en que el componente Hd4puede utilizar otros mecanismos, e.g., una pantalla tactil para proveer la reaccion medianteuna interfaz grafica de usuario y RFID para detectar la reaccion mediante la proximidad a undespliegue.

Las Palabras claves (D3) se pueden obtener a partir del enriquecimiento de la

presencia (Hd2), de la sugerencia de contenido (Hd3) y de la deteccion de reaccion

(Hd4), mientras que la popularidad de elementos (D4) puede ser generada a partir de ladeteccion de reaccion (Hd4).

El componente de adaptacion (A3) puede ejecutarse al combinar el patron individual

de presencia (D2) con las Palabras claves (D3) para que el sistema de despliegue puedaseleccionar el mejor contenido para una preferencia individual, e.g., si algunas personas expresan

Capıtulo 3 59

su interese respecto a un deporte, entonces el sistema podrıa mostrar el contenido relacionadocon ese deporte en un momento dado.

El componente de adaptacion (A4) tiene como objetivo proporcionar elementos similares enlas personas. Esta adaptacion permite al sistema encontrar intereses de contenido, sin necesidadde que los usuarios los expresen de manera explicita.

Hasta la fecha no se han implementado casos de prueba para este marco.

3.6 Marco y Arquitectura para Recomendaciones de

Conciencia de Contexto Grupal

El marco para Recomendaciones de Conciencia de Contexto Grupal (RCCG) provee sugerenciasde contexto tanto para modo grupal como para modo individual. Este marco esta implementadomediante una arquitectura cliente-servidor [Hussein et al., 2010].

La arquitectura propuesta se denomina Vistas de Contexto Hybreed. Hussein et al. incluyenel termino “vista de contexto” para referirse a un estado virtual que se genera a partir deuna secuencia de operaciones de contextualizacion. El contexto se refiere a incluir informacionexterna a las circunstancias (e.g, tiempo y lugar) como informacion derivada de la interaccionde los usuarios con el sistema (e.g., descargas e historial de navegacion).

La arquitectura Vistas de Contexto Hybreed esta representada mediante un diagrama declases que contiene los siguientes elementos: AgenteDeContexto, AdministradorDeEstado,MecanismoDeSensado, MecanismoDeVista, Vista, RepositorioDeEstado y AdaptadorFinal,de las cuales MecanismoDeSensado, FlujoDeTrabajo y la AdaptadorFinal son interfaces (cf.Figura 3.5).

AdaptadorDePuntoFinal MecanismoDeVista

MecanismoDeSensado

AgenteDeContexto AdministradorDeEstado

Vista FlujoDeTrabajo

RepositorioDeEstado

0..*

0..*

0..*

1

1

1

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 individ-ual o grupal de los usuarios, e.g., si la ubicacion de un usuario ha cambiado o si un usuariodio clic sobre un cierto ıcono. Esta clase (ubicada en el servidor) recibe la notificacion, porparte de un cliente, acerca de algun cambio en el estado actual de un usuario, lo cual implicala actualizacion de dicho estado. La clase AdministradorDeEstado tambien puede recibir lapeticion del estado global de un grupo. Dicha solicitud implica que el servidor solicite el estadode cada cliente. Debido a que el estado global es la suma de los estados individuales, Husseinet al. sugieren un mecanismo de bloqueo para evitar un problema de concurrencia. Depen-diendo de la configuracion realizada por los desarrolladores, el evento de actualizacion podrıadesencadenar en el servidor algunas operaciones de inferencia.

La clase MecanismoDeSensado infiere informacion del estado, e.g., determina la localizaciongeografica de un usuario a partir de la direccion IP proporcionada por el cliente.

La clase RepositorioDeEstado se encarga de almacenar estados individuales o grupales yopcionalmente de guarda el contexto del grupo. En el caso del estado global de un grupo, elrepositorio podrıa usar sentencias para representar el estado de un grupo. Dichos datos podrıanguardarse un servidor central.

La clase MecanismoDeVista habilita un proceso de contextualizacion cuando un cliente realizala busqueda de un estado virtual.

La implementacion de la interfaz FlujoDeTrabajo describe como un estado cambia dentrode una contextualizacion. Hussein et al. proporcionan un ejemplo de flujo de trabajo paraejemplificar algunas recomendaciones. Dicho ejemplo puede ser remplazado por algoritmos decontextualizacion ya que estos no estan incluidos en el marco.

Los algoritmos de recomendacion que se implementaron para la arquitectura propuesta corres-ponden a:

• la denotacion de elementos relevantes mediante reglas;

• la propagacion de la activacion se refiere al intercambio de informacion entre nodos, yaque al activarse uno o mas nodos se pueden llegar a activar nodos adyacentes que tienencierto grado de relacion semantica con los primeros nodos;

• el filtro colaborativo considera varios metodos para transferir tanto la vista de contextocomo el trabajo a los colaboradores que forman parte de un grupo, considerando carac-terısticas en comun;

• las aproximaciones hıbridas se refieren a la utilizacion de algunos de los algoritmos men-cionados, e.g., uso de un filtro colaborativo para obtener ciertos elementos, los cualespueden utilizarse como mecanismo de activacion en el algoritmo de propagacion de laactivacion.

Bajo este marco se implemento la arquitectura propuesta, ası como la librerıa Hybreed

Capıtulo 3 61

RecFlow. Dicha librerıa es una implementacion de la interfaz FlujoDeTrabajo, pero no sereporta el desarrollo de alguna aplicacion en especıfico.

3.7 Marco Generico de Contexto

El marco Generico de Contexto (GC) es un marco conceptual para aplicaciones adaptativas alcontexto que considera aspectos internos y externos al sistema. Tambien pretende combinarparametros individuales tanto en contextos cooperativos como en contextos diferentes. Estemodelo abarca la conciencia de contexto y la adaptacion al contexto [Haake et al., 2010].

Haake et al. sugieren que antes de utilizar el marco GC se debe definir dos puntos: 1)la situacion en donde la adaptacion es necesaria, y 2) las acciones de adaptacion que debenejecutarse para mejorar la colaboracion.

3.7.1 Capas de conocimiento, estado, contextualizacion y

adaptacion

El marco GC esta dividido en cuatro capas: de conocimiento, de estado, de contextual-

izacion y de adaptacion (cf. Figura 3.6).

La capa de conocimiento es la base principal de este marco, cuyo objetivo es proveerlos fundamentos necesarios para representar tanto el modelo del dominio como los diferentesaspectos de contexto, e.g., entorno fısico, dispositivos de computo y modelo del usuario. Estacapa requiere de los siguientes componentes para lograr su proposito: modelo de dominio,reglas de inferencia, conocimiento concreto y abstracto.

El conocimiento abstracto puede ser inferido del conocimiento concreto, e.g., una per-sona esta en un cuarto (conocimiento abstracto), lo cual se deriva a partir del hecho quePaul esta en el cuarto LF283 (Conocimiento concreto). Las reglas de inferencia son lasque se encargan de hacer la inferencia de un conocimiento a partir de otro.

El modelo de dominio tiene como funcion almacenar tanto el conocimiento abstracto

como el concreto, ası como enviar y recibir informacion de la capa de estado. A este nivel,la informacion obtenida puede ser de varios tipos: de un usuario, de una situacion indepen-diente, informacion neutral, informacion del sistema o informacion externa estatica, e.g., lacapital de un paıs. Este modelo contiene varias clases para el manejo de la comunicacionsıncrona y asıncrona por medio de audio, video y chat, conciencia sıncrona y asıncrona, admin-istracion (e.g., sesion, concurrencia y usuario), ası como editores compartidos (texto, imagen ycalendario).

La capa de estado contiene informacion de la situacion actual, del entorno fısico y com-putacional, recursos y un modelo del usuario, e.g., ¿en donde esta el usuario?, ¿que hora es? y


Capa de adaptación

Capa de conocimiento

Capa de estado

Capa de contextualización

Modelo de dominio

Estado

Estadocontextualizado

Estado deadaptación

Reglas deinferencia

Reglas de sensado

Reglas decontextualización

Reglas deadaptación

Conocimientoconcreto pre-

Conocimientoabstracto

predefinido

Figura 3.6: Marco Generico de Contexto

¿cual es la circunstancia actual? A este nivel se obtiene un modelo del estado actual, mediantegrafos de estado. Los componentes de esta capa corresponden a las reglas de sensado y elmodelo de estado.

Las reglas de sensado toman informacion interna y externa al sistema, ası como elConocimiento concreto mediante el modelo de dominio (ambos ubicados en la capa de

conocimiento) para reflejar el estado individual y sus propiedades.

La capa de contextualizacion provee tecnicas que definen un subconjunto de un estadoque es relevante para cierto enfoque, el cual es un subconjunto no vacio de objetos del modelode estado que representa en cierto momento, el centro de atencion del sistema. El enfoquesirve como entrada inicial para ejecutar las tecnicas de contextualizacion. Los componentes enesta capa corresponden a las reglas de contextualizacion (tecnicas de contextualizacion)y al estado de contextualizacion.

Las reglas de contextualizacion seleccionan aquellas partes de todo el estado que sonrelevantes 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 1has pref com channel ?Com c) Y (?Person 2 has pref com channel ?Com c) ENTONCES?Com c. La regla de contextualizacion infiere que ambos colaboradores tienen preferencia por elmismo canal de comunicacion (?Com c), el cual es agregado al estado de contextualizacion.

Capıtulo 3 63

El estado de contextualizacion puede verse como un filtro, cuyo resultado es un grafopor cada enfoque (e.g., usuario o grupo) que sirve para la adaptacion.

Finalmente, la capa de adaptacion contiene las reglas de adaptacion que describen queaccion de adaptacion se ejecuta en que caso. Las reglas de adaptacion incluyen operacionespara cambiar propiedades del entorno cooperativo o variables de estado (e.g., mostrar o iniciaralguna aplicacion). Como resultado de esta capa, la adaptacion se refleja en la interfaz deusuario.


Haake et al., proponen algunos dominios de aplicacion de los sistemas colaborativos, ası comouna serie de escenarios en donde puede aplicarse el marco propuesto.

Los dominios de los sistemas colaborativos estan representados mediante diagramas de blo-ques. Los dominios considerados son: artefactos compartidos (imagen, documento, etc.), roles,espacio de trabajo, tarea a resolver, actividades de los colaboradores y aplicaciones colaborati-vas.

Por otro lado los escenarios, representados mediante el lenguaje OWL (Web Ontology Lan-guage), estan divididos respecto a situaciones cooperativas tales como co-localizacion, co-acceso,co-recomendacion y co-dependencia. Cada escenario ejemplifica la situacion de dos personasque colaboran en la redaccion de un documento. A continuacion se exponen los puntos impor-tantes a considerar en cada escenario: la deteccion tanto de participantes colocalizados comolos dispositivos en uso (co-localizacion); la habilitacion de funcionalidades en un sistema co-laborativo dado el rol de un colaborador (co-acceso); la recomendacion de informacion dadauna solicitud previa (co-recomendacion), y la manipulacion de tareas, e.g., la asignacion au-tomatica o manual, las prioridades entre ellas, la fecha lımite y la dependencia entre ellas(co-dependencia).

El proceso de adaptacion de este marco sigue el ciclo tradicional de adaptacion, el cual consistede las fases siguientes: accion del usuario, sensado, seleccion de la adaptacion y ejecucion dela adaptacion. Mediante este proceso se puede representar el proceso de adaptacion del marcoCG de la siguiente manera:

• el sensado tiene como entrada la informacion proveniente del exterior e interior del sis-tema y del modelo de dominio (capa de conocimiento). Las entradas anteriores sonprocesadas mediante reglas de sensado para generar o modificar el modelo de estado

(capa de estado);

• la seleccion de la adaptacion esta representada por la contextualizacion que tiene comoentrada el modelo de estado (capa de estado), el cual es procesada por las reglas de

contextualizacion cuya tarea es establecer el estado de contextualizacion (capa

de contextualizacion);


• la adaptacion tiene como entrada el estado de contextualizacion (capa de con-

textualizacion), el cual es procesado por las reglas de adaptacion (capa de

adaptacion). Esta fase tiene como objetivo ejecutar la adaptacion correspondiente,e.g., mostrar informacion relacionada o encender/apagar un proyector.

El marco GC permite extender las aplicaciones colaborativas con adaptacion al contexto.La extension se logra mediante una arquitectura conceptual (cf. Figura 3.7), la cual pretendedar una opcion para unir una aplicacion colaborativa con un soporte de adaptacion al con-texto. 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 aplicacion a exten-der. El marco GC esta compuesto por el modulo servidor de adaptacion, el cual incluyetres mecanismos (sensado, adaptacion y contextualizacion) que representan el procesode adaptacion mencionado en el parrafo anterior.

Capa de modelo

IU de la aplicación

Capa de servicio

Capa de lógica

Capa de IU

Repositorio compartido

Servicios

Servicios deaplicación

Servicios decolaboración

IU de laaplicación 1

IU de laaplicación 2

Componentede adaptación

Artefacto 1 Artefacto 2 Artefacto 3

Modelo de contexto

Servicios de contexto

Servidor de adaptaciónLógica de la aplicación

Lógica de laaplicación 1

Serviciosbásicos

Notificador

Modelo delMGC

Servicios delMGC

Mecanismode sensado

Mecanismode adaptación

Mecanismo decontextualización

Lógica de laaplicación 2

Figura 3.7: Arquitectura conceptual del marco generico de contexto

Capıtulo 3 65

Otro modulo importante que contiene servicios del marco es el servicio de contexto,el cual accede y manipula el modulo modelo de contexto. Este esta conformado por losdiferentes modelos del marco, e.g., modelo de dominio, sensado de reglas y el estado.

En la arquitectura propuesta se debe habilitar primero el mecanismo de adaptacion parapermitir cambios en las IU de la aplicacion por medio del componente de adaptacion.Dicho componente llama a funciones de adaptacion, las cuales son proporcionadas por losdesarrolladores de la aplicacion. Despues de habilitar el mecanismo de adaptacion, se habilitael mecanismo de sensado para monitorear la interaccion del usuario con la aplicacion y loscambios en el entorno de computo mediante los servicios basicos, los cuales interceptan alas llamadas de las interfaces desarrolladas y registradas previamente por los desarrolladores.

La notificacion informa tanto a la logica de la aplicacion como al servidor de

aplicacion acerca de los cambios relevantes de la configuracion. El componente de

adaptacion se encarga de iniciar o detener las IU de la aplicacion, ası como de usar unainterfaz especıfica para realizar la adaptacion en el modulo mencionado. Las interfaces men-cionadas permiten trabajar sobre los componentes de la interfaz grafica de usuario, e.g., mostrar,ocultar y modificar los componentes.

Los desarrolladores del marco GC implementaron la arquitectura conceptual propuesta, endonde la IU de la aplicacion funciona como plugins para el entorno de desarrollo Eclipse.El prototipo reportado une la aplicacion CURE (Collaborative Universal Remote Education) yR-OSGi 3 para administrar tanto en espacios de trabajo como en documentos, ademas Haake etal. proveer conciencia asıncrona y comunicacion. Los servicios basicos se refieren al accesodel usuario, a la administracion de sesion, a la autenticacion, al acceso a la base de datos y alsensado.

Mediante la implementacion de la arquitectura, Haake et al. consideran que su marco GCpuede ser operacional. No crearon una aplicacion especıfica, pero a partir de cuatro escenariospropuestos, los cuales son relevantes porque denotan situaciones tıpicas del trabajo colab-orativo (co-localizacion, co-acceso, co-recomendacion y co-dependencia), se crearon pruebasfuncionales.

3.8 Analisis comparativo de los marcos analizados

En la Tabla 3.2 se analizan dos puntos importantes de los marcos revisados. El primer puntoes conocer si los marcos estan disenados para sistemas mono-usuario o colaborativos. Eneste caso se aprecia que tanto el marco RUIUM-O4 como CAMELEON-RT se enfocan en

3http://r-osgi.sourceforge.net/4Referencia Unificado para Interfaces de Usuario Multi-Objetivo


sistemas mono-usuario. En cambio, los marcos restantes (PI5, PEC6, ACCDP7, RCCG8 yGC9) se especializan en sistemas colaborativos, ya que el marco PI tiene como objetivo ofrecerplasticidad y conciencia de grupo a los sistemas cooperativos, en cambio el marco PEC combinala conciencia de grupo con la plasticidad. Por otro lado, el marco ACCDP pretende proveerde adaptacion de conciencia de contexto en despliegues publicos, en donde los desplieguesconsideran el trabajo cooperativo.

Nombre del marcoconceptual

ColaborativoNombre(s) de laimplementacion

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 implementacion de los marcos estudiados

Es importante hacer notar que tanto el marco RCCG como el GC tienen la caracterıstica deabordar el trabajo individual o grupal, ya que el primero tiene como objetivo proveer recomen-daciones para ambos ambitos mencionados; en tanto que el marco GC aborda ambos ambitosya que a partir de tomar en cuenta aspectos individuales, e.g., determinar la ubicacion de ciertousuario, puede formarse una idea grupal.

El segundo punto importante en la Tabla 3.2 es conocer si los marcos tienen algun tipo deimplementacion. El marco RUIUM-O no implementa algun ejemplo de prueba, dicho marco seprobo al compararse con algunas herramientas previamente publicadas, las cuales siguen similar

5Plasticidad Implıcita6Plasticidad Explicita Cooperativa7Adaptacion de Conciencia de Contexto en Despliegues Publicos8Recomendaciones de Conciencia de Contexto de Grupo9Generico de Contexto

Capıtulo 3 67

metodologıa que la sugerida en dicho marco. Por otro lado, CamNote y I-AM son aplicacionescreadas con base en el marco CAMELEON-RT. Dentro de los marcos cooperativos, el marcoPI se encuentra en vıas de implementacion, hasta el momento se encuentra en desarrollo laparte del servidor. Mientras que bajo el marco PEC se reporta la herramienta AB-UIED quepermite la produccion automatica de interfaces plasticas, pero no para ambientes cooperativosya que no se implementaron los modulos concernientes al entorno cooperativo, e.g., el modelode grupo. Es importante hacer notar que con la herramienta AB-UIED no se reporta algunaaplicacion.

El marco RCCG fue implementado mediante librerıas al igual que algunos algoritmos paraproveer la recomendacion de conciencia de contexto, solo que no se reporta alguna aplicacionque haga uso de todas estas librerıas. Por otro lado, Haake et al., autores del marco GC, imple-mentaron la arquitectura propuesta para unir el marco GC con las aplicaciones cooperativas.Ellos a partir de los escenarios reportados obtienen pruebas funcionales, las cuales son usadaspara probar la implementacion de la arquitectura.

La implementacion de interfaces de usuario plasticas multimodales generan un espacio delproblema, e.g., adaptacion al contexto de uso, percutores de plasticidad, granularidad de lainterfaz de usuario, granularidad del estado de recuperacion, etc. Hasta el momento, se consi-deran siete elementos que conforman el espacio del problema (cf. Seccion 2.1).

Una de las siete dimesiones del espacio del problema de mayor relevancia para este trabajode investigacion es la dimension contexto de uso, la cual considera la adaptacion al usuario,al entorno y la plataforma sin perder usabilidad. Dicha dimension se analiza en la tabla 3.3. Elmarco RUIUM-O considera por completo la dimension contexto de uso tanto en el modeloOntologico como en el arquetıpicos; en este marco se considera al usuario de manera general ensus modelo Usuario, ubicado en los modelos ontologicos y arquetıpicos, pero podemos observarque existe el modelo tareas para referirse a la tarea del usuario. En cambio, los modelosplataforma permiten hacer la descripcion de los componentes disponibles, ası como clasificarlosen plataforma basica, e.g, computadora personal, o en clusters. Los modelos entorno contienencaracterısticas genericas para describir los entornos adyacentes.

El marco CAMELEON-RT abarca por completo el contexto de uso, i.e., considera alusuario, el entorno y la plataforma. Dicho marco considera la plataforma, la cual esta compu-esta por hardware (e.g., sensores y superficies de despliegue) y software (e.g., Sistema Operativo(SO) y las aplicaciones en ejecucion), mediante varios componentes del marco, e.g., la capa deplataforma y el administrador, para anunciar la llegada o salida de algun dispositivo o informarque sistema interactivo esta ejecutando el usuario. Tambien este marco, CAMELEON-RT,abarca el entorno a partir de la infraestructura de contexto y el observador del lugar

fısico para proveer un modelo del lugar fısico; por ultimo abarca al usuario por medio delobservador de usuario, el cual puede proveer informacion relevante, e.g., perfil del usuario,la ubicacion y posicion relativa.

El marco PEC estima por completo el contexto de uso, ya que considera al usuario medi-ante varios modelos, e.g., usuario, dominio y tarea, para tener conocimiento de caracterısticas,


Marco con-ceptual

Usuario Plataforma Entorno

RUIUM-O tareasbasica oclusters

caracterısticasgenericas del lugar

CAMELEON-RT

perfil yubicacion fısica

software yhardware

modelo del lugar

PI no especifica no especifica no especifica

PEC

tareas,preferencias,

nivel deconocimiento,objetivos ysituaciones

software ycontabiliza losrecursos fısicos

tiempo,condiciones

ambientales ymeteorologicas

ACCDPidentifica yenriquece lapresencia

no especificadeteccion departicipantes

RCCGestado grupal o

individualno especifica

proporcionartrabajo amiembros

GC

preferencias,grupos, tarea,rol, acciones y

actividades

aplicaciones ydispositivos de

computo

artefacto,deteccion departicipantes,

tiempo,co-localizacion,

espacio de trabajo,recomendacion de

informacion

Tabla 3.3: Analisis de los marcos con relacion al contexto de uso

e.g., conjunto de tareas que puede llevar a cabo el colaborador, preferencias, objetivos, nivel deconocimiento, situaciones y necesidades. El PEC aborda la plataforma por medio del modelo deplataforma para contabilizar los recursos fısicos ası como las caracterısticas de software. Final-

Capıtulo 3 69

mente, el marco mencionado contempla el entorno usando el modelo espacial y el de ambientepara obtener la descripcion del exterior, de tal manera que se pueda obtener una conciencia deubicacion, tiempo (hora y dıa de la semana) y las condiciones ambientales (luz del dıa, nivel deruido ambiental y condiciones ambientales y meteorologicas.

El marco GC tambien aborda totalmente la adaptacion al contexto de uso mediante lascapas de conocimiento y estado; en la primera capa se infiere y se almacena los componentes delcontexto de uso, entorno, usuario, y plataforma; mientras que en la capa de estado se modelael contexto de uso tomando informacion interna y externa al sistema ası como informacion dela capa de conocimiento. Las capas anteriores, conocimiento y estado, detectan los cambiosen el contexto de uso. Este marco aborda de diferentes maneras la dimension usuario, e.g, laspreferencias de los colaboradores con relacion al canal de comunicacion, como se menciona enlas reglas de contextualizacion (capa de contextualizacion); el artefacto que estan los colabo-radores manipulando en el momento, la formacion de grupos, varios aspectos de la tarea:la tarea a resolver, las prioridades entre ellas, el deadline, la dependencia entre ellas y laasignacion automatica o manual; el rol y aspectos dependientes del rol: los permisos de acceso,y las actividades de los colaboradores. En el caso de la dimension plataforma se consideralas aplicaciones y el uso de diferentes dispositivos. Finalmente, este marco considera variosaspectos de la dimension entorno compartido, e.g., consideracion del artefacto, deteccion departicipantes, tiempo (hora actual), co-localizacion, y las acciones permitidas en las aplicacionesconsiderando el rol.

Tanto el marco ACCDP como el marco RCCG aborda parcialmente el contexto de uso yaque no especifica la inclusion de la plataforma. El marco ACCDP se centra en el usuario yaque detecta la presencia de los usuarios, e.g., edad, genero y preferencias, mediante las huellasdigitales identificacion y enriquecimiento. Mientras que el marco RCCG considera el estadodel usuario mediante las clases AdministradorDeEstado, MecanismoDeSensado entre otras parainferir la ubicacion o conocer el elemento seleccionado. El entorno es abordado por el marcoACCDP ya que puede detectar la cantidad de personas en un lugar, el genero, etc, sı como lasugerencia de contenido de un grupo mediante las huellas digitales caracterizacion y sugerenciade contenido. El marco ACCDP aborda el entorno cuando proporciona el trabajo a miembrosdel grupo por medio de los algoritmos de recomendaciones.

Por ultimo, el marco PI aborda la adaptacion al contexto de uso basandose en IPE (ImplicitPlasticity Engine); en particular la adaptacion se calcula en la capa de conciencia de contexto,sin especificar a detalle a que se adapta, e.g., nivel de luz.

El resto de las dimensiones del espacio del problema corresponden a percutores de

plasticidad, granularidad de la interfaz de usuario, granularidad del estado

de recuperacion, despliegue, espacio tecnologico y Meta-IU.

El percutor de plasticidad considera la remodelacion, la redistribucion y la migracion.El marco RUIUM-O permite cambios de una plataforma a otra, e.g., de una PC hacia unaPDA, por medio del modulo procesamiento de la reaccion ubicado en la evolucion; por lo tantopodemos decir que este marco implementa la migracion, pero no especifica la implementacion de


la remodelacion ni de la redistribucion. Por otro lado, el marco CAMELEON-RT implementaparcialmente el percutor de plasticidad mediante su capa middleware, dicha capa soportala redistribucion y la migracion de la interfaz de usuario. En cambio, los marcos PI, PEC,ACCDP, RCCG y GC solo mencionan la adaptacion de la interfaz de usuario a cambios contex-tuales cuando sea necesario, pero no indican si esta adaptacion se hace a nivel remodelacion,redistribucion o migracion.

La granularidad de la interfaz de usuario senala el grado en que la interfaz de usuarioha sido metamorfoseada despues de la adaptacion. Dicha granularidad se clasifica en: nivelaplicacion, espacio de trabajo, interactor o pıxel. En este caso todos los marcos analizadosmodifican la interfaz de usuario, solo que no mencionan a que nivel de granularidad cambian.

La granularidad del estado de recuperacion se refiere al grado de preservacion del tra-bajo realizado por el usuario en el sistema antes de la adaptacion plastica. Tres tipos de granu-laridad del estado de recuperacion son posibles: accion, tarea y sesion. El marco RUIUM-Oconsidera la recuperacion del estado mediante el epılogo, perteneciente al modelo de evolucion,al restaurar el contexto de ejecucion; ası que este marco considera la recuperacion sin especi-ficar a que nivel, solo ejemplifican a nivel tarea. El resto de los marcos, CAMELEON-RT,PI, PEC, ACCDP, RCCG y GC, no proporcionan indicios de soportar la granularidad del

estado de recuperacion, aun cuando el marco PEC no especıfica la implementacion de dichagranularidad ya considera almacenar informacion de cada miembro.

El despliegue indica el momento en que se realiza la adaptacion de la interfaz de usuario,i.e., la adaptacion se realiza de manera estatica, al momento de lanzar la aplicacion, o demanera dinamica, en tiempo de ejecucion. Tanto el marco RUIUM-O como PI implementan undespliegue a nivel dinamico; el primero lleva a cabo dicho despliegue mediante sus modelosobservadores que se encargan de describir la realidad, la cual puede ser usada para llevar a cabola adaptacion, y el marco PI implementa el despliegue dinamico gracias a su plantilla IPE.Los demas marcos, CAMELEON-RT, PEC, ACCDP, RCCG y GC, no proveen la informacionnecesaria para determinar el tipo de despliegue implementado.

El espacio tecnologico se refiere a la Ingenierıa Dirigida por Modelos, que puede clasi-ficarse en: intra-espacio, inter-espacios y multi-espacios. Todos los marcos conceptuales(RUIUM-O, CAMELEON-RT, PI, PEC, ACCDP, RCCG y GC) no ofrecen suposicion algunade permitir la implementacion del espacio tecnologico; excepto RUIUM-O ya que consideracambiar de codigo ejecutable cuando no sea soportado por el nuevo contexto, solo que no indicasi cambia o permanece en el mismo espacio tecnologico.

La Meta-interfaz de usuario (Meta-IU) indica al usuario el proceso de plasticidad ycomprende las siguientes categorıas: con negociacion, sin negociacion, plastica e inexistente.En el caso del marco RUIUM-O considera la Meta-IU con negociacion, ya que el desarro-llador puede intervenir en cualquiera de las interfaces de usuario (Abstracta, Concreta y Final)generadas por el marco. Mientras que el marco CAMELEON-RT toma en cuenta la Meta-IU

con negociacion en la capa de sistemas interactivos, ya que los usuarios pueden manipular elespacio interactivo.Por otro lado, el marco PEC contempla el modelo dialogo para establecer

Capıtulo 3 71

el estilo de navegacion, dicho modelo puede considerarse como una Meta-IU con dialogo.Finalmente, los marcos PI, PEC, ACCDP, RCCG y GC no proporcionan suficiente informacionpara determinar algun tipo de implementacion de la Meta-IU

La seccion de analisis termina con la tabla 3.4 para mostrar caracterısticas como tipo de

adaptacion, variables contextuales y tipo de contexto.

Marco con-ceptual

Tipo deadaptacion

Tipo de contextoVariables con-textuales

RUIUM-O no especifica mono-entidad el contexto

CAMELEON-RT

ejecucion mono-entidad plataforma

PI no especifica multi-entidad el contexto

PEC no especifica multi-entidadIU inicial y porpeticion delcliente

ACCDPpresentacion yaumentacion

multi-entidad huellas digitales

RCCG no especifica multi-entidadnotificar o solici-tar el estado

GC no especifica multi-entidad el contexto

Tabla 3.4: Analisis de adaptacion y contexto en los marcos presentados

El tipo de adaptacion se forma por presentacion de la informacion, ejecucion automaticade un servicio e informacion aumentada. Los marcos RUIUM-O, PI, PEC, RCCG y GC noespecifican que tipo de adaptacion puede llevarse a acabo, ya que este tipo lo define el desarro-llador. En cambio, el marco CAMELEON-RT lleva a cabo un tipo de adaptacion catalogadacomo ejecucion automatica al llevar a cabo la redistribucion o migracion de la IU. El marcoACCDP proporciona ejemplos de adaptaciones, los cuales cubren dos tipos de adaptacion, laprimera corresponde a presentacion de la informacion cuando se siguiere mostrar informacionrelevante a cierto grupo; la segunda pertenece a la informacion aumentada al mostrar infor-macion de interes en cierto lugar.

El tipo de contexto se refiere a considera una sola entidad, mono-entidad, o considerar


varias entidades de forma simultanea, multi-entidad. Aun cuando el marco RUIUM-O y elmarco CAMELEON-RT consideran multiples variables contextuales, e.g., plataforma, entorno ytareas, dicho marco son mono-entidad ya que se centra en satisfacer un solo usuario. Los marcosrestantes pertenecen a la clasificacion multi-entidad; ya que los marcos PI y CG tienen comoobjetivo mostrar la conciencia de grupo, mientras que el marco GC pretende proveer concienciade contexto grupal o individual. El marco ACCDP es multi-entidad porque considera tanto lasreacciones como las sugerencias de los usuarios presentes en un lugar, para proveer algun tipode adaptacion. Finalmente, el marco RCCG implementan un contexto a nivel multi-objetivoya que considera los estados individuales de los usuarios para despues generar un estado grupal.

Las variables contextuales son la variables relevantes consideradas para llevar a cabola adaptacion. Los marcos RUIUM-O, PI y GC tienen una variable general, ya que antecualquier cambio en el contexto la adaptacion tiene que llevarse a cabo. Por otro lado, el marcoCAMELEON-RT tiene como variable contextual la plataforma, ya que a partir de detectaruna plataforma puede migrar o distribuirse. En cambio, el marco PEC realiza la adaptacionpara producir la IU inicial y cada vez que el cliente requiera la adaptacion. El marco ACCDPlleva a cabo la adaptacion cuando ocurre cambio en algunas de las huellas digitales siguientes:presencia, presencia enriquecida, sugerencia de contenido y deteccion de reaccion. Por ultimo,el marco RCCG tiene como variables contextuales la actualizacion del estado de un usuario ola solicitud del estado global.

3.9 Conclusiones

Los marcos descritos en esta seccion fueron seleccionados debido a que implementan algunasde los caracterısticas de las interfaces de usuario plasticas multimodales.

Dado el analisis de los marcos con respecto al contexto de uso se puede observar que existe latendencia en considerar varias peculiaridades del usuario , e.g., el perfil, las tareas asignadas yel rol, con la finalidad de proveer una mejor adaptacion. Las caracterısticas anteriores cada vezconsideran aspectos muy finos, e.g., las acciones realizadas dentro del sistema y las preferenciasrespecto a un tema. Por otro lado, la adaptacion a la plataforma se centra en acoplarse alas caracterısticas que ofrece cada dispositivo de computo, pero la tendencia en este punto esconsiderar sensores para permitir la conciencia del entorno fısico, ademas de crear clusters demanera dinamica con los dispositivos al alcance de los usuarios. En cuanto la adaptacion alentorno, los marcos estan tendiendo a modelar el entorno fısico, e.g., detectar las personas enun lugar, ası como proporcionar informacion relevante a cada usuario.

Retomando los puntos relevantes de las interfaces de usuario plasticas se observa que losmarcos se inclinan por permitir que los usuarios finales intervengan en la adaptacion medianteuna META-IU, ası como llevar la adaptacion en tiempo de ejecucion, dejando de lado los demaspuntos a considerar.

Capıtulo 4

Analisis de requerimientos del marco

XARE

En este capıtulo se presenta una definicion del contexto de uso de los sistemas mono-usuarioque sirve de base para definir el contexto de uso de los sistemas colaborativos (cf. Seccion 4.1).

Una vez definido este ultimo concepto se puede hacer uso de terminos como grupo de colabo-radores, conjunto de plataformas y entorno comun, los cuales seran usados en varios escenariosque involucran procesos adaptativos. Dichas adaptaciones no han sido consideradas en el estadodel arte analizado en los capıtulos 2 y 3. Para dar una idea mas clara de los requerimientosevidenciados en dichos escenarios, se proponen varias aplicaciones, algunas de las cuales sonreutilizadas en varios escenarios (cf. Seccion 4.2).

Posteriormente, cada escenario contiene tres partes: 1) un preambulo, 2) un objetivo y 3)una aplicacion. El preambulo proporciona brevemente las posibles adaptaciones del escenario,por otra parte el objetivo proporciona la idea general, mientras que la aplicacion ejemplificaun entorno en donde se usa el escenario, el cual evidencia el contexto de uso de los sistemascooperativos involucrados (cf. Seccion ??).

Las aplicaciones desarrolladas, a partir de los escenarios, parten de un conjunto de requerim-ientos funcionales y no funcionales. Despues se presentan los requerimientos de las aplicaciones,estas estan acompanadas de las interfaces de usuario, ası como de las variables contextualesque provocan la adaptacion de dicha aplicacion (cf. Seccion 4.10).

Finalmente, se muestran las conclusiones obtenidas de este capıtulo (cf. Seccion 4.11).

73

74 Analisis de requerimientos del marco XARE

4.1 Contexto de uso

La movilidad de las personas junto con el desarrollo de una amplia variedad de dispositivos deacceso han engendrado nuevos requerimientos en el campo de investigacion de la InteraccionHombre-Maquina (IHM), tales como la capacidad de los sistemas interactivos para ejecutarseen diferentes contextos.

Probablemente la definicion de contexto mas referenciada es la que proponen Dey et. al, lacual dice [Dey et al., 2001]:

“Contexto es alguna informacion que puede ser usada para caracterizar la situacionde una entidad. Una entidad es un usuario, un lugar, un objeto fısico o de computoque es considerado relevante para la interaccion entre un usuario y la aplicacion,incluyendo al propio usuario y a dicha aplicacion.”

4.1.1 Recapitulacion del contexto de uso de los sistemas mono-

usuario

Retomando la definicion de plasticidad de las interfaces de usuario de los sistemas mono-usuario[Calvary et al., 2006], del capıtulo 1, la cual refiere que:

La plasticidad es la capacidad de las interfaces de usuario de adaptarse a cambiosen el contexto de uso, preservando un conjunto de criterios de calidad, como lausabilidad.

Por contexto de uso se entiende la terna <usuario, plataforma, entorno> donde elusuario denota el arquetipo humano que tiene por objeto utilizar el sistema interactivo[Vanderdonckt, et al., 2008]. El elemento usuario contiene varios componentes, algunos deellos son los siguientes: perfil, actividad [Coutaz and Calvary, 2008] y rol. Los componentesanteriores funcionan como factores externos al sistema, ya que cambian segun el usuario ypueden llegar a modificar el conjunto de funcionalidades que ofrece el sistema.

En el ambito de los sistemas mono-usuario los factores anteriores (perfiles, actividades yroles) han sido estudiados por los desarrolladores de software. Algunos de los estudios se hanenfocado en adaptar las funcionalidades de un sistema a diferentes perfiles de usuario. Laadaptacion se lleva a cabo de manera personalizada, ya que las necesidades y preferenciasde un usuario solo afectan a la instancia del sistema que el esta ocupando, sin afectar a lasinstancias de los demas usuarios. Algunos ejemplos de este tipo de adaptacion serıan informara los usuarios de una librerıa sobre la llegada de nuevo material segun el perfil de cada uno deellos [Amato and Straccia, 1999] y permitir a los usuarios decidir la manera en que desean sercontactados dada una situacion determinada [Stan et al., 2008].

Capıtulo 4 75

El elemento plataforma se refiere a los dispositivos de hardware y software disponiblespara sostener la interaccion del usuario con el sistema. La plataforma puede ser modeladaen terminos de los recursos computacionales que determinan la forma en que se procesa, setransmite y se presenta la informacion, ası como la manera en que el usuario manipula lainformacion. Comunmente el tamano de la memoria, el ancho de banda de la red y la plataformade interaccion motivan la seleccion de un conjunto de modalidades de E/S y la cantidad deinformacion disponible [Calvary et al., 2004, Calvary et al., 2001].

El elemento entorno describe las condiciones fısicas y sociales donde tiene lugar la in-teraccion, e.g., los objetos, las personas y los eventos que son perifericos a la tarea que seesta desarrollando en un momento dado, pero que pueden tener un impacto en el compor-tamiento: a) del sistema, e.g., un entorno ruidoso puede eliminar la realimentacion por audio,y/o b) del usuario, e.g., su localizacion provee un contexto para la relevancia de la informacion[Calvary et al., 2004, Calvary et al., 2001].

4.1.2 Contexto de uso de los sistemas cooperativos

El desarrollo de un espacio de interaccion cooperativo puede resultar complejo, ya que debe con-siderar varios aspectos, e.g., las actividades de los colaboradores y la conciencia de grupo. Dour-ish y Bellotti definen conciencia de grupo como: un conocimiento de las actividades de otrosque provee un contexto para las actividades propias. Algunos investigadores consideran que laconciencia puede clasificarse en cuatro tipos [Gutwin et al., 1995, Dourish and Bellotti, 1992]:

• conciencia informal: permite conocer tanto la ubicacion de los colaboradores como suestado de disponibilidad;

• conciencia de grupo estructural: proporciona conocimiento de roles, responsabilidades,posicion social o profesional;

• conciencia social: permite el entendimiento tanto del contexto social como del conversa-cional, y

• conciencia de espacio del trabajo: permite dar informacion sobre la interaccion de losdemas en el espacio compartido.

Considerando las definiciones previas de conciencia de grupo y de contexto de uso, se proponeutilizar la terna siguiente <grupo de colaboradores, conjunto de plataformas, entorno

comun> para denotar el contexto de uso de los sistemas cooperativos. La terna propuestaconsidera la conciencia de grupo, e.g., durante la asignacion de una tarea se debe considerarel dispositivo de computo del colaborador, ya que este puede tener limitaciones que podrıanimpedir la realizacion de la actividad.

El elemento grupo de colaboradores denota los arquetipos humanos que usan el sistemacooperativo para llevar a cabo un proyecto comun.


El elemento conjunto de plataformas se refiere a las caracterısticas de hardware y softwarede los dispositivos de computo que alojan al sistema cooperativo y que son usados de maneraindividual por cada colaborador (e.g., una computadora portatil o un telefono inteligente) ode forma compartida por algunos miembros del grupo (e.g., un pizarron inteligente). Esteelemento tambien incluye los dispositivos que permiten un mejor funcionamiento del sistema(e.g., impresoras y servidores).

El elemento entorno comun concierne a las condiciones fısicas y sociales, e.g., personas,objetos y eventos, que son externos al grupo de trabajo pero que tienen una influencia tantoen los miembros del grupo como en el sistema cooperativo. Este elemento tambien incluyeun entorno virtual (e.g., espacios de trabajo publicos y privados, objetos compartidos). Eldesktop se define como un conjunto de aplicaciones disponibles para un colaborador, e.g., uncolaborador puede tener un dominio de aplicacion (e.g., editor colaborativo) diferente por cadarol [Haake et al., 2010]. Los objetos compartidos se refieren al texto, a las imagenes, al audio,al video que son compartidos por los colaboradores a traves de un espacio de trabajo publico.

4.2 Relacion entre escenarios y aplicaciones

La tecnica usada para crear el marco XARE es la de bottom-up, por consiguiente se partio deun conjunto de escenarios que nos sirvieron para identificar algunas necesidades de los sistemascooperativos adaptables a cambios contextuales.

Los cambios contextuales abordados en esta tesis se ponen en evidencia en los siete escenariospropuestos (cf. Figura 4.1). Algunos de los escenarios hacen referencia a herramientas com-putacionales para dar una mejor explicacion. En la figura 4.1, los rectangulos que representana los escenarios tienen diferentes colores: verde oliva, amarillo, verde limon y rosa, con el finde denotar el grado de aportacion al desarrollo del marco XARE. El color verde oliva indicaque se detectaron suficientes aplicaciones para automatizar el escenario; el color amarillo indicaque las aplicaciones identificadas no han sido implementadas y que no se asegura una automa-tizacion completa del escenario; el color verde limon indica que las aplicaciones encontradas noson suficientes como para automatizar el escenario, y el color rosa indica que hasta el momentono se han encontrado aplicaciones que puedan automatizar el escenario.

Ası como los escenarios estan marcados con diferentes colores, los aplicaciones tambien hansido representados con diferentes colores: azul, naranja y rojo, para denotar su estado deavance. El color azul representa a las aplicaciones implementadas; el color verde correspondea las aplicaciones en proceso de desarrollo y el color rojo indica que las aplicaciones han sidoidentificadas pero no implementadas.

Para una mejor descripcion de la Figura 4.1, se explicara primero las aplicaciones identifi-cadas:

1. la barra de colaboradores [Romero et al., 2013] expresa la conciencia de grupo mediante la

Capıtulo 4 77

Escenario 3: Redistri-

bución del sistema

colaborativo en

función de la

configuración

Escenario 4: Adaptar

los medios de

contacto y

disponibilidad

Escenario 1:

Mejoramiento del

trabajo colaborativo

Escenario 6: Adaptar

la información

Escenario 7: Uso de

diferentes modalidades

en la notificación

Escenario 5: Ocultar

información (texto,

imágenes, etc.)

Herramienta de

votación

Desktop

enriquecido

Administrador de

contenidos vía NFC

Editor de dibujos

Herramienta de

medios de contacto

y disponibilidad

Editor de mapas

mentales

Barra de

colaboradores

Editor de textos

Aplicación identificada pero no implementada

Aplicación implementada

Escenario completo con aplicaciones identificadas e

implementadasEscenario con ninguna aplicación identificada

Escenario con aplicaciones insuficientes para automatizar

el escenario

Escenario con algunas aplicaciones identificadas pero

no todas están implementadas

Aplicación en proceso de desarrollo

Escenario 2:

Remodelación de

componentes de la IU

Figura 4.1: Escenarios y aplicaciones

foto y el nombre de los colaboradores pertenecientes a un grupo. Dicha barra organiza a loscolaboradores, dependiendo su ubicacion fısica, como: presentes, virtualmente presentesy ausentes;

2. la herramienta de votacion [Romero et al., 2013] permite a un grupo de colaboradoresparticipar en una votacion electronica de manera anonima o conocida;

3. el editor de mapas mentales [Romero et al., 2013] faculta la creacion de diagramas paraorganizar ideas.

Es importante mencionar que la herramienta de votacion y el editor de mapas men-tales permiten tanto la interaccion co-localizada como la distribuida. Ambas aplicacionesmuestran los iconos relacionados al rol del colaborador que esta usando la aplicacion.Finalmente, ambas aplicaciones usan la barra de colaboradores para proveer conciencia


de grupo.

4. el editor de dibujos tiene como objetivo crear imagenes vectoriales, con la caracterısticade que soporta transiciones del trabajo individual al trabajo colaborativo y viceversa.Los colaboradores pueden pasar de su respectivo espacio privado a un espacio comundonde pueden interactuar mediante un dispositivo con una pantalla grande (e.g., unpizarron electronico) o un arreglo de tablets. El paso de un espacio de trabajo privado auno compartido origina que los iconos se adapten a los colaboradores involucrados en lainteraccion, considerando sus roles y sus jerarquıas;

5. la herramienta de medios de contacto y disponibilidad [?] ofrece de manera visual tanto ladisponibilidad como los medios de contacto disponibles de un colaborador, considerandovarios parametros, tanto del colaborador a contactar como del que desea contactarlo;

6. la desktop enriquecido [?] permite relacionar los objetos compartidos entre diferentesaplicaciones para enriquecer el trabajo de los colaboradores involucrados con dicho objetocompartido;

7. el administrador de contenidos vıa NFC [Romero et al., 2013] enriquece las reunionesco-localizadas al proveer informacion extra en el tiempo y lugar indicado, mediante latecnologıa NFC (Near Field Communication);

8. el editor de textos permite ocultar informacion restringida ante personas no autorizadas,quienes estan cerca del area de despliegue de la informacion.

Despues de describir las herramientas, se describiran los escenarios representados en la Figura4.1.

El escenario “Mejoramiento de trabajo colaborativo” pretende enriquecer la colaboracionentre los miembros de un grupo al mantener, en todo momento, el contexto de los objetoscompartidos en el espacio de trabajo y al encontrar algunas relaciones existentes entre loscolaboradores, en funcion de su interaccion con dichos objetos. A partir de las relacionesencontradas, el sistema colaborativo provee sugerencia pro-activa al lanzar en ejecucion otrasaplicaciones para manipular un objeto dado y asociar diferentes conversaciones textuales encurso que hacen referencia a dicho objeto. La herramienta relacionada con este escenario es eldesktop enriquecido.

El escenario “Remodelacion de componentes de la interfaz de usuario” permite la modificacionde componentes mediante las siguientes acciones: ocultar, sustituir o agregar; la modificacionincluye referenciar a otro dispositivo de hardware que proporcione la misma funcionalidaddel componente modificado. Este escenario es importante, ya que sus especializaciones serepresentan en los escenarios del tres al seis. Aun cuando existen particularidades en estosescenarios es importante recalcar que este segundo escenario permite adaptar los ıconos (e.g.,en las herramientas de votacion, de mapas mentales, editor de dibujos y de medio de contactoy de disponibilidad) y las aplicaciones (e.g., desktop enriquecido) en funcion del rol de loscolaboradores.

Capıtulo 4 79

El escenario “Redistribucion del sistema colaborativo en funcion de la configuracion delgrupo” adapta los componentes que son afectados por el trabajo co-localizado y redistribuido.Algunos de los componentes detectados que son susceptibles a dichas modificaciones correspon-den a el espacio compartido y publico, la conciencia de grupo y el uso de dispositivos conpantallas grandes y buena resolucion para una mejor interaccion (e.g., un pizarron electronico).Las herramientas asociadas a este escenario corresponden a: herramienta de votacion, her-ramienta mapas mentales, herramienta de dibujo y herramienta barra de colaboradores.

El escenario cuatro modifica los componentes relacionados con la disponibilidad y los mediosde contacto dependiendo de algunos parametros relacionados con los colaboradores. La her-ramienta relacionada con este escenario es medios de contacto y disponibilidad).

El escenario cinco adapta la informacion desplegada en un dispositivo, e.g., pizarronelectronico o una laptop, al detectar una persona que no pertenece al equipo de trabajo. Aldetectar a dicha persona, la informacion es cambiada por otra de menos relevancia para que nopueda ser visualizada por dicha persona. En este escenario, se envıa una notificacion al restodel grupo de colaboradores acerca de la presencia de alguien ajeno al equipo para que no envıenmensajes u otro tipo de informacion importante en ese momento. La herramienta relacionadaa este escenario corresponde al editor de textos.

El escenario seis permite proveer informacion que puede ser util a los colaboradores, con-siderando el lugar, la fecha y el rol de los colaboradores. Este escenario tiene asociada laherramienta administrador de contenidos vıa NFC.

El escenario siete ofrece una gama de posibilidades para notificar a los colaboradores acercade un evento en especıfico considerando la actividad en curso de cada uno de ellos, ası como laimportancia de dicho evento. Este escenario hasta al momento no tiene asociada una aplicacionen especıfico.

4.3 Escenario 1: Mejoramiento del trabajo colaborativo

Este escenario describe un espacio de trabajo capaz de mantener el contexto de los objetos ma-nipulados por un grupo de colaboradores durante una sesion de trabajo, ası como de relacionardiferentes conversaciones referentes a un mismo objeto compartido y de ofrecer funcionalidadesadicionales (e.g., herramientas) para manipularlo, con el fin de mejorar la colaboracion entrelos miembros del grupo. Antes de describir el escenario, se presenta una introduccion acerca delas aplicaciones cooperativas adaptativas que son usadas en este escenario, ası como los roles yla granularidad de los objetos compartidos soportados por estas aplicaciones.


4.3.1 Preambulo

Para mantener el contexto de los objetos compartidos producidos durante una sesion de trabajo,un grupo de colaboradores depende de un desktop enriquecido que provea varias aplicacionescooperativas disenadas para trabajar en conjunto.

El desktop enriquecido es ejecutado por los colaboradores al momento de ingresar a su sesionpara trabajar en las tareas asignadas. En este caso de estudio, el desktop enriquecido permitela ejecucion de tres aplicaciones, las cuales pueden estar relacionadas entre ellas para proveermas informacion al contexto de trabajo. Las aplicaciones son las siguientes:

1. un editor colaborativo de documentos HTML que permite la fragmentacion para facilitarla produccion concurrente;

2. un pizarron multi-usuario que permite a los colaboradores llevar a cabo sesiones de lluviade ideas y dibujar diagramas con extension JPG;

3. un servicio de mensajerıa que soporta la comunicacion de forma directa entre los colab-oradores.

La granularidad de los objetos compartidos soportada por el editor colaborativo desde unapalabra, una frase, un parrafo o una seccion hasta todo el documento. Por otro lado, el pizarronmulti-usuario tiene diferentes granularidades, las cuales van desde figuras basicas (e.g., lıneas,cuadrados, cırculos y rectangulos) hasta un diagrama completo. La tercera aplicacion soportagrupos no estratificados, mientras las dos primeras soportan tres roles:

1. el rol de coautor permite a los colaboradores escribir texto y dibujar diagramas;

2. el rol de lector da la posibilidad a los colaboradores de leer texto y de visualizar imagenes;

3. el rol de revisor permite a los colaboradores hacer comentarios respecto a la forma y alcontenido del texto y de los diagramas.

Es importante mencionar que no todas las aplicaciones cooperativas adaptativas contenidasen el desktop enriquecido estan visibles en todo momento, para evitar que el usuario se saturecon aplicaciones posiblemente inutiles. Con el objetivo de proveer a los colaboradores con unespacio de trabajo apropiado, las herramientas estan disponibles dependiendo del rol actualdel colaborador. De este modo, un colaborador con el rol de escritor, solo requiere ejecutaren su desktop enriquecido tanto el editor colaborativo como el pizarron multi-usuario. En elcaso de un colaborador con el rol de revisor, el requiere que la mensajerıa instantanea trabajecoordinadamente con el editor colaborativo y el pizarron multi-usuario para hacer comentariosacerca del texto o los diagramas del documento.

Capıtulo 4 81

4.3.2 Descripcion del escenario

Suponga un grupo compuesto por cuatro miembros, Alice, Isaac, Jenny y Sandy, que estapreparando un reporte tecnico de manera distribuida. Aunque los miembros del grupo utilizandispositivos heterogeneos, estos tienen buenas caracterısticas tecnicas (e.g., gran tamano y altadefinicion de pantalla, ası como buen poder de procesamiento y capacidades de comunicacion).Dadas las caracterısticas de los dispositivos, la adaptabilidad de las aplicaciones colaborativasno se expresa mediante la remodelacion de su interfaz de usuario, sino por las funcionalidadesque dichas aplicaciones proveen para que los miembros del grupo puedan llevar a cabo susactividades.

El equipo de trabajo ha dividido el documento en secciones, ası que cada miembro estaencargado de escribir una seccion, mientras sus colegas son responsables de la revision. De estamanera, los colaboradores pueden escribir el documento de manera concurrente. En particular,Sandy e Isaac han estado trabajando juntos porque sus secciones respectivas estan relacionadas.El mismo caso ocurre con Alice y Jenny, ya que ambas estan encargadas de dibujar todas lasfiguras del reporte tecnico.

Cuando Sandy termina de redactar la primera version de su seccion, le pide a Isaac querevisen conjuntamente dicha seccion, ya que ella tiene algunos problemas para expresar susideas. En consecuencia, ellos deciden entablar una comunicacion directa mediante la mensajerıainstantanea, mientras el editor colaborativo esta encargado de mostrar los parrafos sujetos adiscusion.

Por medio de la funcionalidad deixis que provee la mensajerıa instantanea, los colaboradoressimplemente seleccionan una palabra clave (e.g., this figure, the next section, this paragraph,those references o here) y crean las hiperligas entre esa palabra y un objeto compartido deleditor colaborativo (e.g., un tıtulo, un parrafo, una frase, una palabra, una referencia, unafigura o una seccion) al seleccionar el objeto compartido. Gracias a esta funcionalidad, loscolaboradores no necesitan copiar los parrafos referenciados desde el editor colaborativo hacia lamensajerıa instantanea cuando se esta revisando. De este modo, el parrafo mantiene su contexto(i.e., parrafo anterior y siguiente, figuras asociadas y referencias) en el editor colaborativo (cf.Figura 4.2).

Mediante la funcionalidad deixis, Isaac escribe: “. . . in this paragraph, you are using theconcept “view-controller pair” without defining it . . . ”. En la frase previa, las palabras “thisparagraph” tiene una liga de hipertexto que apunta a un parrafo del documento abierto en eleditor colaborativo. Ası, cuando Sandy da clic en la liga creada por Isaac, el editor colaborativoautomaticamente le muestra el parrafo correspondiente a la mitad de la vista y resaltado conletra de color (morado, en este caso).

Ası como el parrafo en cuestion mantiene su contexto, i.e., referencias bibliograficas, parrafosalrededor y figuras referenciadas, Sandy puede darse cuenta que los comentarios de Isaac estana la derecha para que ella pueda facilmente verificar que el concepto “vista-controlador” noesta definido en parrafos previos de la seccion.


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

interrelatedcomponents.

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.

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:

Hi Sandy

Hello Isaac

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!

Figura 4.2: Uso de las palabras deıcticas “in this paragraph” (en la forma de una liga de hiper-texto) por parte de Isaac en la herramienta de la mensajerıa instantanea para referirse a unparrafo en el editor colaborativo

Mientras Sandy e Isaac estan produciendo una nueva version del parrafo, Alice y Jennytambien decidieron usar la mensajerıa instantanea para hablar acerca de los diagramas quehan creado. La mensajerıa instantanea muestra que Alice escribio “. . . I’d like to highlight H1in this diagram” (cf. Figura 4.3). Ası como Isaac, Alice ha usado las palabras clave “in thisdiagram”, el cual tiene una liga de hipertexto hacia la figura 1 del reporte tecnico desplegadoen el editor colaborativo. De este modo, cuando Jenny da clic sobre la liga de hipertexto creadapor Alice, el editor colaborativo muestra el diagrama correspondiente a la mitad de la vistaresaltandolo mediante un borde color azul.

Este diagrama tambien mantiene su contexto, i.e., seccion contenedora, tıtulo de la figura,parrafos circundantes. Como no es posible modificar este diagrama desde el editor colaborativo,el espacio de trabajo compartido provee una funcionalidad a los colaboradores para hacer unacopia de tal diagrama en el pizarron multi-usuario, donde este puede ser modificado. La copiamantiene una referencia contextual al diagrama mostrado en el editor colaborativo (en este

Capıtulo 4 83

Hi Jenny! I’d like to highlight H1 in

this diagram as it’s the key node…

Hello Alice! I agree with you, so

shoulders to the wheel!

Jenny

Alice






















Figura 4.3: Uso de las palabras deıcticas “in this diagram” (en la forma de una liga de hiper-texto) por parte de Alice en la herramienta de la mensajerıa instantanea para referirse a la Fig.1 del pizarron multi-usuario

caso, un identificador de objeto interno y la localizacion del objeto en el documento). Ası, encualquier momento, tal diagrama puede ser modificado en el pizarron multi-usuario, el cualpermite a los colaboradores remplazar facilmente la version anterior en el editor colaborativopor la nueva version creada en el pizarron multi-usuario debido a la referencia contextual.

Como Alice y Jenny deciden modificar tal diagrama, una copia es automaticamente creadaen el pizarron multi-usuario. En este momento, el espacio de trabajo compartido percibe queSandy e Isaac estan escribiendo un parrafo que hace referencia a la figura que esta siendomodificada por Alicia y Jenny. En consecuencia, el espacio de trabajo compartido sugiere aSandy e Isaac seguir la conversacion de Alice y Jenny porque puede ser de interes, ya que ellasestan modificando la figura asociada al parrafo que ellos estan redactando. Esta sugerencia estambien hecha a Alice y Jenny. Ası que Sandy e Isaac estan interesados en seguir la conversacionde Alice y Jenny (cf. Figura 4.4) y viceversa (cf. Figura 4.5), ellas pueden acceder a este pormedio de una nueva pestana agregada en los mensajeros instantaneos, respectivos.


You’re right!

May I define it after this phrase?






















Hello Sandy

Hello Isaac

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!

Figura 4.4: Se sugiere a Sandy e Isaac seguir la conversacion de Alice y Jenny porque ellasestan modificando la figura referenciada por el parrafo que ellos estan modificando

Para adaptar las actividades de los colaboradores, el espacio de trabajo compartido tienecomo objetivo hacer mas eficiente el trabajo grupal. Gracias a esta funcionalidad, los cuatrocolaboradores pueden coordinar facilmente su trabajo al evitar errores, duplicaciones innece-sarias, y malos entendidos. Si es necesario, estos colaboradores pueden comunicarse directa-mente para coordinar sus respectivos trabajos, sin perder el contexto de la produccion conjuntade los objetos compartidos.

Adaptacion al contexto de uso de los sistemas cooperativos

En este escenario, la adaptacion al contexto de uso se aborda de dos maneras. La primerapermite la adaptacion al grupo de colaboradores, ya que considera el rol del colaborador paradesplegar las aplicaciones relacionadas con ese rol. La segunda forma de adaptacion consideraal entorno compartido, ya que se hace referencia a un objeto compartido de manera directao indirecta, e.g., en el escenario se detecta que Sandy e Isaac estan describiendo una figura, la

Capıtulo 4 85

Fonts for H1 should be in red….

Jenny

Alice






















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!

Figura 4.5: Se sugiere a Alice y Jenny seguir la conversacion de Sandy e Isaac porque ellosestan reescribiendo el parrafo que refiere a la figura que ellas estan modificando

cual esta siendo modificada por Jenny y Alice.

4.3.3 Desktop enriquecido

Este desktop enriquecido permite la interaccion de tres aplicaciones que son: mensajerıa in-stantanea, editor colaborativo de documentos y un pizarron multi-usuario. Una caracterısticaimportante del desktop enriquecido es que dentro de una conversacion realizada desde la men-sajerıa instantanea, se puede hacer referencia a objetos compartidos desplegados en el editor.Ademas, el desktop enriquecido permite identificar cuando dos conversaciones hacen referenciaal mismo objeto compartido.


Requerimientos funcionales y no funcionales

Los requerimientos funcionales del desktop enriquecido se muestran a continuacion:

• Cada colaborador debe identificarse al ingresar al desktop enriquecido.

• El desktop enriquecido debe reconocer a cada colaborador para adaptar su interfaz deusuario, i.e., mostrar los ıconos de acceso rapido a las aplicaciones relacionadas con el rolasignado.

• Cada colaborador podra usar la funcion Deixis perteneciente a la mensajerıa instantaneapara crear diferentes ligas que referencien diferentes objetos compartidos, los cualespueden ser parrafos, palabras, imagenes, etc. Dichos objetos estan ubicados en el ed-itor colaborativo.

• El colaborador debe hacer una serie de pasos para crear una referencia deıctica, los cualesincluyen: 1) seleccionar el ıcono deixis para desplegar la ventana llamada “New Deixis”;2) seleccionar las palabras que serviran de referencia deıctica, e.g., this paragraph dentrode la ventana abierta 3) seleccionar en el editor colaborativo el objeto compartido al quese hara referencia deıctica, y 4) aceptar para terminar de crear la nueva deixis.

• El colaborador podra acceder a dicha referencia deıctica, solo al seleccionar con el raton lapalabra. En consecuencia, el desktop enriquecido podra mostrar en pantalla la referenciaal objeto. En caso de que el objeto referenciado sea un parrafo, este cambiara el color dela letra a rojo para indicar que se esta haciendo referencia a ese parrafo. En caso de queel objeto haga referencia a una imagen, esta estara enmarcada con un recuadro de colorazul.

• El colaborador podra hacer una copia de la imagen referenciada, del editor colaborativo,en el pizarron multi-usuario para hacer modificaciones sobre dicha imagen. Una vezterminadas las modificaciones, el objeto sera actualizado en el documento de textos,donde ha sido referenciado.

• El colaborador podra seguir una conversacion sugerida por el desktop enriquecido, una vezque este ultimo detecte que dos conversaciones hacen referencia a un objeto compartido.

Los requerimientos no funcionales del desktop enriquecido corresponden a:

1. El desktop enriquecido debe mostrar en medio de la vista del editor colaborativo el objetocompartido al que se esta haciendo referencia.

2. El desktop enriquecido debe permitir la creacion de varias referencias deıcticas en unaconversacion, ası como mantener las ligas a dichos objetos.

Capıtulo 4 87

3. El colaborador que reciba la deixis, e.g., in this paragraph, desde la mensajerıa instantaneaveran que esta palabra esta en color azul y subrayada.

4. El desktop enriquecido esta encargado de abrir el pizarron multi-usuario cuando los colab-oradores deseen crear una copia de una imagen referenciada. Ademas, los colaboradoresautorizados seran responsables de incluir la copia de la imagen requerida, ası como depermitir que dichos colaboradores autorizados modifiquen y actualicen la imagen.

Interfaces de usuario

El desktop enriquecido proporciona informacion aumentada de tres maneras: 1) muestra lasaplicaciones relacionadas con los roles asignados; 2) localiza facilmente textos o figuras creadosen un editor colaborativo desde un mensajero instantaneo (cf. Figuras 4.2 y 4.3), y 3) sugierea los colaboradores seguir las conversaciones publicas de sus colegas que estan relacionadas conel trabajo en desarrollo (cf. Figura 4.4 y 4.5).

Las variables contextuales que son consideradas para la adaptacion contextual correspon-den a: 1) rol del colaborador, 2) la referencia deıctica, 3) objetos compartidos en uso y 4)conversaciones actuales.

Una de las variables contextuales se refiere al rol que puede tener asignado el colaborador.Cuando el colaborador tiene asignado el rol de coautor, de lector o de revisor, el tendraaccesible las aplicaciones del editor colaborativo y el pizarron multi-usuario, con la variante deque el rol de revisor tendra acceso a mensajerıa instantanea.

La variable referencia deıctica es realizada por un colaborador desde la mensajerıa in-stantanea. Dicho referencia resalta las figuras o el texto sin que estos pierdan su contexto.

La variable objetos compartidos en uso debe contener los objetos que estan usando todos loscolaboradores que estan interactuando en un momento dado. Dicha variable permite identificarel grado de relacion entre dichos objetos compartidos, para proveer sugerencia pro-activa.

La variable conversaciones actuales registraran las las conversaciones de los colaboradoresen un momento dado. Esta variable permitira que dichas conversaciones sean visualizadas porotros colaboradores como resultado de la sugerencia pro-activa.

Proceso de adaptacion contextual

En los siguientes parrafos se describen los eventos que provocan adaptaciones contextuales:

1. Un colaborador inicia sesion en el desktop enriquecido. Al momento en que dichodesktop enriquecido autentifica al colaborador; posteriormente, este solicita a una base dedatos los roles del colaborador para determinar las aplicaciones relacionadas con los rolesobtenidos, con la finalidad de ponerlas accesibles al colaborador, e.g., un revisor requiere


acceder al editor colaborativo, a la mensajerıa instantanea y posiblemente al pizarronmulti-usuario.

2. Un colaborador crea una referencia deıctica. La creacion de referencias deıcticases posible cuando los colaboradores estan llevando a cabo una conversacion por mediode la mensajerıa instantanea. Para crear dicha referencia, ellos tiene que seleccionar laopcion deixis en la mensajerıa ası como alguna de las palabras deıcticas, tales como:this figure, the next section, this paragraph, those references o here. Como consecuencia,la mensajerıa resalta la palabra seleccionada al subrayarla, ası como cambia el estilo anegrita y establece el color azul marino (cf. Figura 4.3).

3. Un colaborador selecciona una referencia deıctica desde la herramienta de

mensajerıa. Posterior a la seleccion de la referencia deıctica, el objeto ligado a dichareferencia (e.g., una figura o un texto como una palabra, un parrafo o una seccion) esmostrado y resaltado en el editor colaborativo, con la finalidad de que dicho objeto nopierda su contexto dentro del documento, i.e. conserve su pagina y ubicacion. Depen-diendo del tipo de objeto seleccionado, algunas de las siguiente adaptaciones puedenocurrir:

(a) el editor colaborativo cambia a la pagina que contiene la figura a mostrar. La figuraes centrada en el area de trabajo, y esta rodeada por un cuadro coloreado. Por otraparte, el editor permite el acceso a la opcion ”Make a copy“;

(b) el editor colaborativo cambia a la pagina que contiene el texto a mostrar, cuya fuentepresenta un color diferente al resto del documento.

4. El colaborador selecciona la opcion ”Make a copy”. Esta opcion es activada despuesde que una figura fue seleccionada a partir de la referencia deıctica. Al seleccionar ”Makea copy“, el desktop enriquecido muestra a los colaboradores involucrados la figura en elpizarron multi-usuario para que puedan modificarla. Internamente, el pizarron multi-usuario crea una referencia (un identificador de objeto y la localizacion en el documento)al diagrama mostrado en el editor colaborativo.

5. Actualizacion de la copia de una figura en el editor colaborativo. El evento deactualizar una copia es generado por los colaboradores que solicitaron dicha copia, desdeel editor colaborativo. Al momento de solicitar dicha actualizacion, el pizarron multi-usuario remplaza la figura del editor colaborativo por la figura que tiene el pizarron.

6. El desktop enriquecido propone seguir una conversacion. Este evento sucede cuandoel desktop enriquecido detecta que varios colaboradores hacen referencia a uno objetocompartido. En consecuencia, el desktop enriquecido, mediante una ventana, proponea los colaboradores en cuestion seguir la conversacion actual que llevan sus colegas pormensajerıa instantanea para facilitar su trabajo, ya que todos estos colaboradores hacenreferencia al mismo objeto.

Capıtulo 4 89

7. Los colaboradores acepta la recomendacion de seguir una conversacion. Silos colaboradores seleccionan el boton Ok de la ventana que sugiere seguir otras conver-saciones, la mensajerıa crea una nueva pestana por cada grupo que hace referencia alobjeto compartido que ellos estan usando. En esta nueva pestana, ellos pueden ver laconversacion en curso de los otros colaboradores (cf. Figura 4.2).

4.4 Escenario 2: Remodelacion de componentes de la

interfaz de usuario

El objetivo de esta propuesta es ocultar, sustituir o agregar componentes de los sistemas coop-erativos. Dichos componentes pueden ser el espacio compartido o privado, los ıconos de accesode una aplicacion, un archivo de texto o de imagenes, parte del contenido de archivos, un ıcono,etc.

4.4.1 Preambulo

En ocasiones los sistemas cubren una amplia gama de funcionalidades, las cuales frecuentementese ven reflejadas en componentes de la interfaz de usuario, e.g., menus o ıconos. La mayorıade las veces los usuarios no utilizan varios componentes por muchas razones. Algunos de losmotivos para ocultar o sustituir los componentes o funcionalidades se mencionan a continuacion:

• mostrar solo los iconos relacionados con su actividad, e.g., si un revisor de un artıculoutiliza un telefono inteligente, entonces el sistema cooperativo que esta utilizando debeocultar el ıcono de insertar imagen debido al reducido espacio de la pantalla;

• ocultar componentes cuando:

– existan componentes innecesarios dado los roles de un colaborador;

– estos no tengan funcionalidad debido a que el recurso humano o fısico asociados noesta disponible, e.g., el ıcono de una impresora debe ocultarse cuando esta descom-puesta;

• sustituir la funcionalidad de un dispositivo que no esta disponible, e.g., el espacio dememoria local es insuficiente para almacenar el trabajo actual, ası que la funcionalidadde guardar informacion localmente puede ser cambiada por guardar informacion en eldispositivo de un colaborador conectado al sistema o en algun servidor.

Una vez que el sistema reduzca el numero de componentes se puede aplicar alguna formade remodelacion descrita por Calvary et al. [Calvary et al., 2006] para adaptar la interfaz deusuario a diferentes situaciones contextuales.


La herramienta que permitira ejemplificar el escenario es un editor de mapas mentales quepermite que los colaboradores puedan asumir los siguientes roles:

• administrador, el cual le permite crear un nuevo mapa mental, elegir a los participantesy asignarles un rol;

• autor, el cual le da la posibilidad de agregar, modificar, mover o eliminar elementos en elmapa mental, y

• revisor, el cual le permite agregar, modificar o eliminar comentarios sobre los elementosdel mapa mental.

Ademas 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 reunion y 2)distribuido (virtualmente presente), cuando algun usuario se encuentra en un lugar diferente alde reunion.

Otra caracterıstica importante de mencionar acerca de la herramienta de mapas mentales serefiere a la dimensiones de la pantalla de un dispositivo. Dichas dimensiones son clasificadas en:1) pantalla pequena, cuando la pantalla del dispositivo es de un tamano menor a siete pulgadasy 2) pantalla grande, cuando la pantalla del dispositivo es de siete pulgadas o mas.

4.4.2 Descripcion

Supongamos que un grupo de colaboradores, compuesto por Coello (Isaac), Fraga (Alicia),Chakraboborty (Jenny), Morales y Mejia, necesita realizar un mapa mental sobre softwarelibre. Dichos colaboradores han planeado formalmente una cita que ha sido registrada en laagenda de la sala de reuniones.

Coello acude a la reunion llevando consigo una laptop, en tanto Alicia asiste cargando untelefono inteligente. Cuando Isaac y Alicia entran a la sala de reuniones, son autenticadosautomaticamente por medio de una etiqueta NFC que se encuentra en la entrada de la sala.Mientras tanto, Jenny entra al sistema manualmente introduciendo su nombre de usuario ycontrasena mediante su tablet PC, ya que ella ha decidido interactuar con sus colegas de maneraremota.

Cuando Isaac se aproxima al pizarron interactivo de la sala de juntas y toca la etiquetaNFC asociada a dicho pizarron, se muestra la pantalla principal que contiene las aplicacionesdisponibles y un mensaje que indica que su sesion ha iniciado. Ademas, se visualiza una barrade colaboradores donde se muestran los colaboradores virtualmente presentes, en este caso, elnombre y la foto de Jenny. Desde la pantalla principal, Isaac ejecuta el editor colaborativode mapas mentales, el cual le asigna el rol de administrador que le permitira seleccionar a loscoautores y asignarles sus respectivos roles. Isaac decide dar el rol de revisor a Jenny y el rol de

Capıtulo 4 91

autor a Alicia. En particular, el rol de autor permite la adicion, o eliminacion y modificacion delos elementos del mapa mental, mientras que el rol de revisor permite la adicion, modificaciony eliminacion de los comentarios asociados a dichos elementos. Una vez que Isaac concluyo laasignacion de roles a los coautores, el editor de mapas mentales se ejecuta automaticamente enlos dispositivos moviles de sus colegas.

La interfaz de usuario del editor de mapas mentales se adapta a las dimensiones de la pantalladel dispositivo, a la configuracion del grupo y al rol del usuario (administrador, autor y revisor).Por lo tanto, en el dispositivos de Alicia, la interfaz de usuario de esta herramienta muestrauna vista radar interactiva [Utwin et al., 1996] donde se presenta unicamente la estructura delmapa mental. Por el contrario, en el pizarron interactivo y en la tablet de Jenny, la interfaz deusuario muestra una vista detallada del mapa mental, ası como un barra de colaboradores quecontiene el nombre y la foto de los participantes virtual y fısicamente presentes.

A traves de la vista radar interactiva mostrada en el dispositivo movil de Alicia pueden anadir,modificar, modificar,mover y eliminar elementos, mientras observan una vista detallada delmapa mental en el pizarron interactivo. Jenny puede agregar, modificar y eliminar comentariosdesde la vista detallada del mapa mental mostrada en su tablet, i.e., el editor de mapas metalesofrece solo las funcionalidades dado el rol del colaborador.

Despues de que Alicia trabaja un largo rato en el mapa mental, ella decide salvarlo en sutelefono inteligente con el cual ha estado trabajando en la sesion actual. Cuando ella seleccionael ıcono de guardar, este despliega un letrero indicando que su telefono inteligente no tienesuficiente espacio para almacenar el diagrama, ası que el editor de mapas mentales proponeutilizar el disco duro de la computadora de Isaac o el de un servidor. Es importante mencionarque el editor no ofrece el disco duro de Jenny porque ella esta fuera de lınea.


La adaptacion de este escenario al contexto de uso de los sistemas cooperativos comprende dosde las tres dimensiones propuestas: grupo de colaboradores y conjunto de plataformas.

La adaptacion al grupo de colaboradores se logra ya que a a partir del rol del colaborador,el editor de mapas mentales decide ocultar los iconos no utilizados. En el caso de Jenny, el editorde mapas mentales solo ofrece las funcionalidades que permiten manipular (agregar, modificary 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 unadetallada dependiendo del dispositivo, y 2) la funcionalidad ”guardar localmente” es sustituidapor guardar en otro dispositivo, e.g., el que esta usando Isaac o en un servidor.


4.4.3 Editor de mapas mentales

La aplicacion de edicion colaborativa de mapas mentales permite a un grupo de colaboradorestrabajar en un documento comun de manera simultanea. Por lo tanto, los cambios realizadospor un colaborador al documento actual son percibidos de manera inmediata por los demasparticipantes. Los colaboradores pueden interactuar con el mapa mental, ya sea a traves dealgun pizarron interactivo ubicado dentro del lugar de reunion o por medio de sus dispositivosmoviles.


Los requerimientos funcionales del editor de mapas mentales se presentan a continuacion:

1. Identificar al administrador del mapa mental.

2. Permitir que el administrador pueda crear un nuevo mapa mental, seleccionar a los par-ticipantes y asignar un rol a cada uno.

3. Adaptar su interfaz de usuario de acuerdo al rol del usuario, a las dimensiones de lapantalla de su dispositivo y a la configuracion del grupo, i.e., si se encuentra trabajandoco-localizadamente o de manera remota.

4. Permitir agregar, modificar o eliminar elementos o comentarios desde una vista detalladamostrada en un pizarron interactivo o una tableta.

5. Permitir agregar, modificar o eliminar elementos o comentarios desde una vista radarinteractiva mostrada en un dispositivo movil.

6. Mostrar una barra de desplazamiento horizontal y una vertical cuando las dimensionesdel mapa mental sobrepasen a las del pizarron interactivo.

7. Permitir exportar el mapa mental a una imagen en formato png.

Los requerimientos no funcionales del mapa mental son los siguientes:

1. Permitir que dos o mas usuarios puedan agregar elementos al mapa mental si-multaneamente.

2. Maximizar la eficiencia mediante la navegacion con un lapiz (en caso de utilizar unpizarron interactivo) o una pantalla tactil (en caso de utilizar dispositivos moviles).

3. Tanto en el pizarron interactivo como en una tableta, se deben distinguir claramente losdetalles del mapa mental a una distancia considerable.

4. Reflejar inmediatamente, en todos los dispositivos, las modificaciones hechas por unusuario sobre el area de dibujo del mapa mental.

Capıtulo 4 93

Interfaz de usuario

Para llevar a cabo la adaptacion al contexto, la aplicacion considera las siguientes variables:1) el rol del colaborador, 2) la configuracion del grupo y 3) las dimensiones de la pantalla deldespliegue.

Los roles que puede asumir un usuario son: 1) administrador, 2) autor y 3) revisor. Escribirque pasa en cada caso.

La configuracion del grupo puede ser: 1) co-localizado (fısicamente presente), cuando todoel grupo se encuentra en el mismo lugar de reunion y 2) distribuido (virtualmente presente),cuando algun usuario se encuentra en un lugar diferente al de reunion. La dimensiones dela pantalla de un dispositivo son clasificadas en: 1) pantalla pequena, cuando la pantalla deldispositivo es de un tamano menor a siete pulgadas y 2) pantalla grande, cuando la pantalladel dispositivo es de siete pulgadas o mas.

La herramienta editor cooperativo de mapas mentales cambia su interfaz de usuario depen-diendo del rol del colaborador, e.g., revisor o autor. Tanto los roles como el nombre del mapason asignados por un colaborador mediante una ventana (cf. Figura 4.6).

Figura 4.6: Eleccion de participantes y sus roles en la creacion del mapa mental

Despues de haber asignados los roles, cada colaborador recibira una notificacion para par-ticipar en el desarrollo de dicho mapa mental. La IU para los colaboradores con rol de revisor


podran ver el mapa mental y agregar en cada nodo un comentario (cf. Figura 4.7), por talrazon pueden ver los iconos que permiten agregar, eliminar o modificar un comentario.

Figura 4.7: Vista del mapa mental cuando el colaborador asume el rol de revisor

La IU para los colaboradores autores contiene los iconos necesarios para agrega un nodo,editarlo o eliminarlo, pero no podran hacer comentarios. Dicha interfaz tambien les muestrauna vista del mapa mental (cf. Figura 4.8).

Esta herramienta tambien cambia la IU dependiendo del trabajo co-localizado o distribuido,ası como las caracterısticas de la pantalla. En el caso de los colaboradores co-localizados podrantener dos IU de usuario dependiendo del tamano de la pantalla. Pantallas para telefonosinteligentes pulgadas se muestra sin detalles el mapa mental (cf. Figura 4.9a); en cambio,dispositivos como tablets tendran aun vista detallada del mapa mental (cf. Figura 4.9b).

Finalmente, los colaboradores distribuidos deben tener una pantalla de 8 pulgadas o mas, yaque ellos requieren a detalle el mapa conceptual, ası como la barra de colaboradores (cf. Figura4.10).

La adaptacion al contexto, en esta herramienta considera las siguientes variables contextuales:1) el rol del colaborador, 2) la configuracion de grupo y 3) las dimensiones de la pantalla deldespliegue. Los roles que puede asumir un usuario son: 1) administrador, el cual permite crearun nuevo mapa mental, elegir a los participantes y asignar un rol a cada uno de ellos, 2) autor,el cual permite a un colaborador agregar, modificar, mover o eliminar elementos en el mapa

Capıtulo 4 95

Figura 4.8: Vista del mapa mental cuando el colaborador asume el rol de autor

mental y 3) revisor, el cual permite a un colaborador agregar, modificar o eliminar comentariosen el mapa mental. La configuracion de grupo puede ser: 1) co-localizado (fısicamente presente),cuando todo el grupo usuario se encuentra en el lugar de reunion y 2) distribuido (virtualmentepresente), cuando algun usuario se encuentra en un lugar diferente al lugar donde se llevaa cabo la reunion. La dimensiones de la pantalla de un dispositivo son clasificadas en: 1)pantalla pequena, cuando la pantalla del dispositivo es de un tamano menor a siete pulgadas y2) pantalla grande, cuando la pantalla del dispositivo es de siete pulgadas o mas.

Proceso de desarrollo de mapas mentales

A continuacionse describe con mayor detalle el proceso que se lleva a cabo para crear un mapamental. Se asume que un grupo de colaboradores se reune en una sala de juntas que cuenta conun pizarron interactivo. Durante el proceso de edicioncolaborativa, la aplicacion pasa a travesde tres fases principales:

• Inicializacion de un nuevo mapa mental: cuando el organizador de la reunion pasaa la zona donde se encuentra el pizarron interactivo, su presencia es detectada al acercarsu dispositivo movil a la etiqueta NFC asociada a dicho pizarron y, como resultado deesta accion , su sesion es iniciada automaticamente. Desde el pizarron interactivo, elcolaborador selecciona el editor colaborativo de mapas mentales, el cual le otorga el rolde administrador. En consecuencia, la aplicacion muestra una pantalla donde se enlis-


(a) Vista radar in-teractiva en los dis-positivos moviles delos colaboradores co-localizados

(b) Vista detallada en los disposi-tivos moviles de los colaboradores co-localizados

Figura 4.9: Adaptabilidad de la interfaz de usuario del editor de mapas mentales con base enla configuracion de grupo y las dimensiones de la pantalla de despliegue

tan los colaboradores tanto fısicamente presentes como virtualmente presentes. Desdedicha pantalla el administrador puede seleccionar a los colaboradores participantes en lacreacion del mapa mental y asignar el rol que asumira cada uno (ver Figura ??). Al ter-minar tal proceso, la aplicacion envıa una notificacion de participacion a los dispositivosde los colaboradores elegidos por el administrador. Ademas, la aplicacion presenta en eldespliegue compartido la vista inicial del mapa mental, la cual muestra unicamente elnodo raız desde donde se podran agregar mas elementos.

• Edicion del mapa mental: una vez que los colaboradores seleccionaron la notifi-cacion de participacion en la creacion de un mapa mental, la aplicacion se ejecuta au-tomaticamente y muestra una interfaz de usuario adaptada de acuerdo al contexto de usodel usuario (ver Figura ??). Con base en el rol del usuario (autor o revisor), la interfazde usuario muestra las acciones disponibles y oculta las acciones restringidas para ese rol.Ademas, en funcion de la configuracion del grupo y de las dimensiones de la pantalla deldispositivo, se muestra ya sea una vista radar interactiva o una vista detallada del mapamental.

• Finalizacion y exportacion del mapa mental: despues de que los colaboradores, en

Capıtulo 4 97

Figura 4.10: Vista detallada en los dispositivos moviles de los colaboradores distribuidos

comun acuerdo, han decidido que el mapa mental esta concluido, el administrador puedeexportar dicho mapa a una imagen en formato png para su impresion o reproduccion.

Con el fin de mostrar la manera en que el editor colaborativo de mapas mentales se adapta alos cambios contextuales, se describe una lista de eventos que provocan la adaptacion de dichoeditor:

1. un administrador selecciona a los colaboradores participantes, asigna el rol de cada uno ycrea el nuevo mapa mental: cuando el administrador inicia un nuevo mapa mental se envıauna notificacion a los dispositivos moviles de los participantes presentes y virtualmentepresentes, donde se solicita su participacion;

2. un colaborador con rol de revisor selecciona la notificacion de participacion en la creaciondel mapa mental: se ejecuta el editor colaborativo de mapas mentales en su dispositivo yla interfaz de usuario de dicho editor se adapta de tal manera que despliega unicamentelas opciones disponibles para el rol del colaborador (autor o revisor ). A continuacion sepresentan las opciones disponibles para cada colaborador de acuerdo a su rol:

• autor: permite agregar, editar, mover y eliminar elementos en el mapa mental;

• revisor: permite agregar, editar o eliminar comentarios en el mapa mental;


De igual manera, la interfaz de usuario se adapta de acuerdo a la combinacion de las sigu-ientes variables contextuales: a) configuracion de grupo y b) dimensiones de la pantallade despliegue. La IU se adapta de tres maneras, dos de ellas ocurre en una interaccioncara a cara con dispositivos pequenos (vista radar interactiva) y con dispositivos grandes(vista detallada). En el caso de los colaboradores distribuidos, ellos solo podran usardispositivos como tablets para tener una vista detallada y la barra de colaboradores (cf.Figura 4.10). La vista radar interactiva muestra la estructura del mapa mental, ya quelas dimensiones de la pantalla del dispositivo no permiten una buena visibilidad de los de-talles del mismos . Tanto para los colaboradores co-localizados como para los distribuidoscon dispositivos con pantalla grande, la vista detallada muestra toda la informacion delmapa mental, i.e., la etiqueta de cada nodo y la etiqueta de las conexiones entre nodos,si existen. Para los participantes distribuidos, se muestra adicionalmente una barra quemuestra los colaboradores fısicamente presentes, virtualmente presentes y ausentes en ellugar de reunion (ver Figura 4.10).

En el caso del pizarron interactivo, tambien se presenta una vista donde se puede observarcon detalle el mapa mental y una barra que muestra unicamente a los colaboradoresausentes y virtualmente presentes.

3. Un colaborador agrega, modifica o elimina elementos o comentarios: los cambios reali-zados por el colaborador, ya sea autor o revisor, se ven reflejados en los dispositivos detodos los colaboradores y en el pizarron interactivo;

4. El mapa mental sobrepasa las dimensiones del pizarron interactivo: la vista del mapamental muestra una barra de desplazamiento horizontal y una vertical, tanto en el pizarroninteractivo como en los dispositivos moviles.

Proceso de adaptacion contextual

4.5 Escenario 3: Redistribucion del sistema colaborativo

en funcion de la configuracion del grupo

Este escenario pretende proveer funcionalidades necesarias cuando los colaboradores estan tra-bajando co-localizadamente (cara a cara) o distribuidamente.

4.5.1 Preambulo

Los grupos de colaboradores no siempre trabajan de manera co-localizada o distribuida, enalgunas ocasiones trabajan de manera hıbrida, i.e., algunos de manera co-localizada y otros demanera distribuida en una misma sesion colaborativa. Algunos de los componentes a modificarson los siguientes:

Capıtulo 4 99

• la barra de colaboradores puede sufrir algunos de estos cambios;

1. eliminar la foto y el nombre de los colaboradores que integran en ese momento elgrupo co-localizado, ya que dichos integrantes estan conscientes de los participantespresentes;

2. informar a los colaboradores que trabajan de manera distribuida acerca de los miem-bros del grupo que estan trabajando tanto de manera co-localizada como de maneradistribuida;

• el espacio publicode trabajo compartido en una sesion co-localizada podrıa ser desplegadoen dispositivo con una pantalla de despliegue lo suficientemente grande para que la infor-macion sea visible a todos los integrantes. Por otra parte, el espacio de trabajo privadopodrıa ser mostrado en los dispositivos personales de cada integrante;

• la barra de herramientas de un sistema colaborativo en una sesion co-localizada podrıamostrar los ıconos relacionados con los roles de los integrantes de dicha sesion.

4.5.2 Planteamiento del escenario 3

Supongamos un grupo de colaboradores formado por Sandy, Alice, Isaac y Jenny trabajan enla redaccion de un reporte tecnico de un producto nuevo de software. Sandy e Isaac tienen elrol de autor, cuya actividad es hacer los diagramas de clases; mientras, Jenny tiene el rol derevisora, cuya actividad es revisar todo el documento. Alice tiene dos roles: autor y revisor.

Todos los miembros del equipo se encuentran trabajando de manera remota en la partedel documento asignado. Sandy y Alice crean una cita en una agenda cooperativa con lafinalidad de aclarar ciertas dudas con respecto a los diagramas. El lugar elegido para llevar acabo la reunion es una sala de juntas que tiene un pizarron electronico. Una vez reunidas lascolaboradoras ingresan al espacio de trabajo desde sus iPad’s. Ambas abren los diagramas declases en la aplicacion pizarron multi-usuario.

Alice puede abrir los diagramas con ciertas restricciones debido a su rol. En consecuencia, elsistema solo ofrece los iconos relacionados, e.g., agregar notas y guardar. En el caso de Sandy,ella tiene acceso a varios iconos que Alice no, e.g., agregar clases, agregar relaciones y modificardiagramas. Sandy cuenta con mas iconos que Alice debido a su rol.

Despues de que ellas ingresan a la herramienta pizarron multi-usuario, el sistema detectaque ambas trabajan en el mismo lugar fısico (co-localizadamante) y que ademas ambas estantrabajando sobre las mismas imagenes. Por lo tanto, el sistema realiza las siguientes tareas deforma simultanea: 1) informa a Isaac y a Jenny que Alice y Sandy estan colaborando juntas y2) propone adaptar la interfaz de Sandy y Alice.

La tarea de informar, a Isaac y a Jenny, que Alice y Sandy estan colaborando juntas involucramodificar la barra de conciencia de todo el grupo de la siguiente forma:


• Jenny e Isaac visualizan que las fotos de Alice y Sandy estan ubicadas al mismo nively estan encerradas con un recuadro. Esta accion le causa extraneza a Jenny, ası queella coloca su cursor sobre la foto de Sandy, como consecuencia el sistema le notifica queambas estan trabajando co-localizadamente;

• Alice y Sandy solo ven las fotos de Isaac y Jenny en su barra de colaboradores, ya que elsistema deduce que ellas no requieren ver sus fotos puesto estan colaborando en el mismolugar.

La tarea de adaptar la interfaz de Alice y Sandy sigue esta secuencia de pasos:

1. al detectar que ambas colaboradoras trabajan cara a cara, el sistema propone a ambasutilizar el pizarron electronico para mostrar el espacio publico y dejar en sus dispositivospersonales el espacio privado. Ambas colaboradoras aceptan usar el pizarron electronicopara desplegar el espacio publico, ya que se les facilita tener en una sola vista los diagramasa discutir;

2. el sistema tiene que decidir que funcionalidades de la aplicacion mostrar ya que ambascolaboradoras tienen diferentes privilegios sobre los diagramas de clases, e.g., Alice solopuede hacer comentarios sobre dichos diagramas debido a que tiene el rol de revisora,en cambio Sandy puede modificar dichos diagramas. El sistema puede resolver de variasmaneras el problema anterior, las cuales son:

• combinar las funcionalidades de ambos roles, i.e., unir los ıconos que tienen accesocada una, sin duplicar ıconos;

• mostrar en el pizarron electronico las funcionalidades que coinciden, dejando en susdispositivos personales los ıconos que quedaron fuera de la interseccion de sus roles;

• en caso de que el sistema no pueda tomar una decision, este debe proponer a lascolaboradoras las opciones por medio de una meta-IU para que ellas elijan la masadecuada

Las colaboradoras dejan que el sistema determine las funcionalidades apropiadas. En estecaso, el sistema combina las funcionalidades de ambos roles, ya que es una opcion elegida fre-cuentemente. Una vez que aparecen dichas funcionalidades sobre el pizarron electronico, elsistema muestra el espacio publico sobre este mismo dispositivo. En dicho espacio se muestranlos diagramas que ambas habıan abierto en sus respectivos dispositivos, excepto algunos dia-gramas de clases que Sandy habıa realizado. Los diagramas no son mostrados porque no soncomunes entre ambas colaboradoras.

Cada colaboradora tiene en sus iPad’s su espacio privado, que puede ser solo visto por ellas.Ellas pueden arrastrar diagramas hacia el borde superior de sus iPad’s, lo cual es interpretadopor el sistema como una instruccion de pasar el diagrama seleccionado desde su iPad hacia elpizarron electronico, que contiene el espacio comun

Capıtulo 4 101

Adaptacion del contexto de uso de los sistemas cooperativos

Este escenario se adapta al grupo de colaboradores, al conjunto de plataformas y alentorno comun.

La adaptacion al grupo de colaboradores se logra cuando se muestran los ıconos rela-cionados al rol de los colaboradores co-localizados, Alice y de Sandy.

La adaptacion al conjunto de plataformas ocurrio cuando el sistema sugiere usar elpizarron electronico al detectar que existe un grupo de colaboradores trabajando cara a cara,ya que el lugar de trabajo tiene instalado dicho pizarron.

La adaptacion al entorno comun se logra cuando se asigna el espacio publico en el pizarronelectronico y el espacio privado en sus dispositivos personales. Otra forma de adaptarse esteescenario a esta dimension ocurre cuando muestra quienes trabajan de manera co-localizada ode manera distribuida en la barra de conciencia.

4.6 Escenario 4: Adaptar los medios de contacto y de

disponibilidad

El objetivo de esta propuesta es modificar el medio de contacto y de disponibilidad de doscolaboradores dependiendo de las actividades, preferencias y el dispositivo en uso.

4.6.1 Preambulo

Los sistemas cooperativos permiten diferentes formas de comunicacion, e.g., mensajerıa in-stantanea y correo electronico, entre los colaboradores. Dichos sistemas no permiten que demanera automatica varıen los medios de comunicacion dependiendo de la actividad, del disposi-tivo o de la aplicacion, ya que estos son cambiados rapidamente dependiendo de las necesidadesde los colaboradores.

De igual manera podrıa establecerse de manera automatica el estado de disponibilidad de loscolaboradores al considerar su actividad. Sin dejar de lado la opcion de que los colaboradorespuedan establecer manualmente dicha disponibilidad o el medio de contacto.

4.6.2 Planteamiento del escenario

Un grupo de colaboradores, cuyos nombres corresponden a Isaac, Alicia y Jenny, se encuentratrabajando a distancia en la redaccion de un reporte tecnico para un nuevo producto de soft-ware. En particular, Isaac y Sandy tienen que redactar la seccion de desarrollo, aunque Isaac


tambien es responsable de escribir la seccion de introduccion. Finalmente, Alice y Sandy estanrespectivamente encargadas de escribir y revisar la seccion de conclusiones, pero Alice tieneasignado revisar la seccion de introduccion y de desarrollo.

Isaac, ingresa al espacio de trabajo, para terminar algunas subsecciones de la seccion dedesarrollo, ya que la fecha lımite de esta actividad esta relativamente cercana. Ası, basadoen las preferencias de Isaac, el espacio de trabajo determina su disponibilidad (cf. Mecanismodisponibilidad 5.2.2) como sigue:

1. Ocupado para los colegas: a) cuya actual actividad es muy poco similar o no similar a lasuya, aun si una de sus potenciales actividades es mas o menos similar o poco similar asu actividad actual, y b) cuya actividad actual o potencial son muy poco o no similaresa su actual actividad.

2. Alcanzable si es posible para los colegas: a) cuya actividad es mas o menos o poco similara la suya, y b) cuya actividad actual es muy poco o no es similar a la suya, pero una desus potenciales actividades es similar o muy similar a su actual actividad.

3. Accesible para los colegas, cuya actividad es similar o muy similar a la suya.

Entonces, Isaac define sus propios medios de contacto basados en sus sub-estados de disponi-bilidad (el primer parametro de entrada):

1. Cuando el esta ocupado, el puede ser contactado por correo electronico, ası que temas norelacionados a su actividad actual seran tratados cuando el pueda/quiera.

2. En el caso de estar accesible si es posible, el podra ser contactado solo por mensajerıainstantanea, para ser informado inmediatamente de algun tema y retrasar su respuestaen caso de ser necesario.

3. Cuando el este accesible, el podra ser contactado por video-conferencia, voz o mensajerıainstantanea porque, desde su punto de vista, los medios de comunicacion directa en tiemporeal hacen entendible las ideas y sugerencias relacionadas con su actividad actual.

Cuando Alice y Sandy ingresan al espacio compartido, ellas prefieren que este infiera sudisponibilidad y sus medios de contacto. Tanto Alice como Sandy deciden trabajar en laseccion de conclusiones, ellas colocan su cursor en dicha seccion, para empezar a escribir yredactar respectivamente. Dado que la fecha lımite de esa actividad es relativamente distante,el espacio de trabajo determina los siguientes sub-estado de su disponibilidad:

1. Ocupadas para colegas, cuya actual y potencial actividades sean poco o no similares a susactuales actividades.

Capıtulo 4 103

2. Alcanzables si es posible para colegas, cuya actual actividad es muy similar o no similara las suyas, pero una de sus potenciales actividades es muy similar, similar, mas o menossimilar o poco similar a su actual actividad.

3. Accesible para colegas, cuya actual actividad es muy similar, similar, mas o menos similar,o poco similar a ellas.

Ademas, el espacio de trabajo establece el medio de contacto de Sandy basado en la simi-laridad entre sus actividades y las actividades de sus colegas, considerando las preferencias deSandy. De esta manera, ella puede ser contactada a traves de:

1. Anotaciones privadas en el texto o correo electronico por colegas, cuya actividad actualo potencial son muy similares o similar a su actual o potencial actividad. En este caso,Sandy ha seleccionado esos medios de contacto, ya que estos aseguran la persistencia dedatos.

2. Sus medios de contacto preferidos, mensajerıa instantanea o voz, de otra manera.

El espacio de trabajo de Alice tambien determina sus medios de contacto basado en laproximidad logica entre ella y sus colegas dentro del espacio. Ası, ella puede ser contactada atraves de:

1. Anotaciones privadas en el texto por colegas que estan trabajando en el mismo objetocompartido que esta siendo accedido por ella.

2. Video-conferencia, voz y mensajerıa instantanea de otra manera.

En todos los casos, la disponibilidad de los medios de contacto dependen del hardware ysoftware de los dispositivos de Isaac, Sandy y Alice.

Imaginemos que Sandy esta revisando la seccion de conclusiones y detiene su actividad,para contactar a Isaac. Ella coloca su cursor en la foto de Isaac (localizado en la barra deconciencia) y como resultado, un widget desplegable aparece para mostrar: la disponibilidadde Isaac y los medios de contacto para comunicarse con el. Sandy nota que la disponibilidadde Isaac es alcanzable si es posible, ya que la fecha lımite de la actividad es cercana, auncuando las actividades no son similares. Ella es tambien responsable de escribir la seccion dedesarrollo; por consiguiente, los medios de contacto de Sandy para comunicarse con Isaac es lamensajerıa instantanea. Sin embargo, ella decide terminar de revisar un parrafo de la seccion deconclusiones, antes de contactarlo. La vista de Sandy tambien muestra su disponibilidad comoaccesible, aunque sus actuales actividades son poco similares, la fecha lımite de la actividad deAlice es distante. El medio de contacto que tiene Sandy para comunicarse con Alice es medianteanotaciones privadas sobre el texto, porque ambas estan trabajando sobre la misma seccion.

Isaac percibe que la disponibilidad de Sandy es ocupado, ya que la fecha lımite de la actividadde ella es distante, sus actuales actividades no son similares, y la actividad potencial de el (i.e.,


escribir la seccion de introduccion) tampoco es similar a la actividad actual de ella. Los mediosde contacto de Sandy son las anotaciones privadas sobre el texto y el correo electronico, porquela potencial actividad de ella (i.e, escribir la seccion de desarrollo) es muy similar a la actualactividad de Isaac. La vista de Isaac muestra que Alice es accesible, ya que la fecha lımitede la actividad de ella es distante, y sus actuales actividades son mas o menos similares. Losmedios de contacto disponibles para que Isaac contacte a Alice son video-conferencia, voz, ymensajerıa instantanea, porque ellos estan trabajando en diferentes secciones.

Igual que Sandy, Alice puede ver que la disponibilidad de Isaac es alcanzable si es posible,ya que la fecha lımite de la actividad de el es cercana, y sus actuales actividades son mas omenos similares. Por lo tanto, los medios de contacto disponibles para que Alice establezcacomunicacion con Isaac corresponden a la mensajerıa instantanea. Distinto a la vista de Isaac,la vista de Alice muestra que Sandy es accesible, aunque sus actuales actividades son pocosimilares, la fecha lımite de la actividad de Sandy es distante. Los medios de comunicaciondisponibles para que Alice contacte a Sandy son la mensajerıa instantanea y voz, porque susactividades actuales y potenciales son mas o menos similares.

Despues, Alice deja la seccion de conclusiones, para trabajar en la seccion de desarrollo. Asıella pone su cursor en esta ultima seccion y empieza a leer lo que escribio Isaac. Cuando elespacio compartido detecta esta accion, no solo los sub-estados de la disponibilidad cambian.Para llegar a un acuerdo acerca de la estructura de la seccion, Sandy pone su cursor en la fotode Isaac otra vez y observa que su estado de disponibilidad es accesible. Ella tambien nota quetiene adicionales medios de contacto para comunicarse. De hecho, la instancia del espacio detrabajo alojado en el dispositivo de Sandy provee esos medios de contacto adicionales, porqueeste ha detectado que Sandy e Isaac estan compartiendo la misma actividad.

De esta manera, los medios de contacto disponibles para que Sandy establezca una comu-nicacion con Isaac son voz y la mensajerıa instantanea, aun cuando Isaac tambien estableciola herramienta de video conferencia como uno de sus medios de contacto preferidos y su dis-positivo es capaz de soportarlo, el dispositivo de Sandy no tiene camara. En consecuencia unasesion de video conferencia no puede llevarse a acabo. En la vista de Sandy, Alice permaneceaccesible, ya que la fecha lımite de la actividad de Alice es distante, y sus actuales actividadesson mas o menos similares. Sin embargo, Los medios de contacto de Alice han cambiado amensajerıa instantanea y voz, porque ellas estan trabajando en diferentes secciones. Es impor-tante mencionar que la herramienta de video-conferencia ha sido seleccionada por Alice, perono esta disponible para Sandy, como se menciono previamente, el dispositivo de Sandy no tienecamara.

En la vista de Isaac, Sandy esta accesible, ya que sus actuales actividades son similares.Por este motivo, los medios de comunicacion disponibles para que Isaac contacte a Sandypermanecen sin cambios. La disponibilidad y los medios de contacto de Alice son las mismas.Por otro lado, la vista de Alice, el medio de contacto y la disponibilidad de Isaac permanecensin cambios, pero Sandy cambia a alcanzable si es posible, las actividades actuales de Alicey Sandy son mas o menos similar, y la fecha lımite de la actividad de Sandy es cercana. Es

Capıtulo 4 105

importante mencionar que los medios de contacto de Sandy no cambiaron, porque su actual ypotencial actividad son mas o menos similar.

Adaptacion del contexto de uso de los sistemas cooperativos

Este escenario aborda dos dimensiones del contexto de uso de los sistemas cooperativos. Dichasdimensiones corresponden a: grupo de colaboradores y conjunto de plataformas.

La adaptacion al grupo de colaboradores ocurre cuando cambia la disponibilidad o losmedios de contacto disponibles dependiendo de la actividad actual o potencial de los colabo-radores.

La adaptacion al conjunto de plataformas se logra cuando se concideran los dispositivosnecesarios para proveer el servicio de un medio de contacto. En el caso de Isaac, el si contabacon una camara Web para hacer la vide-conferencia, pero Sandy no tenia alguna, por tal motivoel 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 de-pendiendo del colaborador a contactar (colaborador observado) y del que desea contactar a uncolaborador en especıfico (colaborador observador). Tanto la disponibilidad como el medio decontacto puede ser calculado de manera automatica, dependiendo de las actividades, roles y ladisponibilidad de los colaboradores involucrados, o de manera manual por parte del colaborador.


Los requerimientos funcionales de la herramienta de disponibilidad y medios de contacto semuestran a continuacion:

1. Un colaborador se identifica ante el sistema herramienta de disponibilidad y medios decontacto.

2. Un colaborador establece manualmente su disponibilidad desde la ventana de configu-racion de disponibilidad. El colaborador puede configurar cada estado de disponibilidad,los cuales corresponden a: ocupado, alcanzable si es posible y accesible. Para configurarcada estado, el colaborador selecciona una o mas de las similitudes entre las actividadesactuales y potenciales del colaborador observador y el observado. Las actividades puedenser muy similar, similar, mas o menos similar, poco similar, muy poco similar o no similar.

3. Un colaborador permite que el sistema establezca automatica su disponibilidad sin necesi-dad de ingresar a alguna opcion ya que esta por omision dicha opcion. En este caso el


sistema debe recurrir al conjunto de reglas fijas que incluyan la similaridad de las activi-dades potenciales y actuales del colaborador observado y observador.

4. Un colaborador establece su medio de contacto de manera manual mediante la ventana deconfiguracion de los medios de contacto. Los medios de contacto corresponden a: video-conferencia, correo electronico, audio, mensajerıa instantanea y anotaciones privadas.Cada medio de contacto sera relacionado con un estado de disponibilidad, ası que cuandose calcule la disponibilidad, los medios de contacto relacionados estaran disponibles parael colaborador observado.

5. Un colaborador permite que el sistema establezca su medio de contacto de manera au-tomatica. El sistema establece dichos medios al recurrir a las reglas establecidas por losdesarrolladores.

6. El colaborador observador solicita la disponibilidad y el medio de contacto del colaboradorobservado al colocar el cursor sobre la foto del observado.

7. Un colaborador selecciona un medio de contacto al dar clic sobre las opciones desplegadas.

Los requerimientos no funcionales de la herramienta disponibilidad y medios de contacto semuestran a continuacion:

1. Para mostrar los medios de contacto disponibles entre dos colaboradores, se debe verificarque ambos tengan el hardware como el software necesario para dicho medio de contacto;

2. El tiempo de verificar el hardware y software necesario para mostrar un medio de contactodebe ser muy breve, escasos segundos;

3. El tiempo para calcular la disponibilidad no debe ser grande, escasos segundos;

4. Informar al colaborador porque no puede llevar a cabo un medio de contacto.


La principal caracterıstica de la herramienta disponibilidad y medios de contacto es adaptartanto la disponibilidad y el medio de contacto al contexto de dos colaboradores, los cualescorresponden al colaborador observado y observador. Dicha adaptacion se ve reflejada en labarra de colaboradores (cf. Figuras 4.11 y 4.12).

En la figura 4.11 se muestra la vista de tres colaboradores que ingresan al sistema. Dichasvistas son diferentes entre cada uno, ya que cada uno hace diferentes actividades (cf. Escenario4.6 para mas detalle).

En la figura 4.12, la disponibilidad y los medios de contacto han cambiado por el simplehecho de que Sandy ha cambiado de actividad, sin que los demas colaboradores cambien deactividad.

Capıtulo 4 107

Collaborators

WriterDevelopment

ReviewerConclusions

WriterConclusions

Sandy

Isaac

Alice

Collaborators

WriterDevelopment

ReviewingConclusions

WriterConclusions

Sandy

Isaac

Alice

Collaborators

WriterDevelopment

ReviewerConclusions

WritingConclusions

Sandy

Isaac

Alice

Reachable if possible

Instant Messenger

Accessible

Private Annotations

Busy

E-mail

Private Annotations

Accessible

Voice

Instant Messenger


Instant Messenger

Accessible

Video-conference

Voice

Instant Messenger

(a) Sandy’s view (b) Isaac’s view (c) Alice’s view

Figura 4.11: Disponibilidad y medios de contacto al inicio de la sesion colaborativa.

Collaborators

WritingDevelopment

WriterDevelopment

WriterConclusions

Sandy

Isaac

Alice

Collaborators

WriterDevelopment

WritingDevelopment

WriterConclusions

Sandy

Isaac

Alice

Collaborators

WriterDevelopment

WriterDevelopment

WritingConclusions

Sandy

Isaac

Alice


Instant Messenger

Accessible

E-mail

Private Annotations


Voice

Instant Messenger

Accessible

Video-conference

Voice

Instant Messenger

Accessible

Video-conference

Voice

Instant Messenger

Accessible

Video-conference

Voice

Instant Messenger

(a) Sandy’s view (b) Isaac’s view (c) Alice’s view

Figura 4.12: Disponibilidad y medios de contacto de Sandy, Isaac y Alice una vez que Sandyha cambiado su actividad.

Las variables contextuales involucradas en la adaptacion de la disponibilidad y el medio decontacto son las siguientes: 1) similaridad de las actividades, 2) objetos compartidos en uso y3) dispositivo en uso. Las variables anteriores son necesarias tanto para la disponibilidad comoel medio de contacto, aunque este ultimo tambien requiere la disponibilidad y las preferenciasdel usuario. Dichas variables estan planteadas a detalle en la propuesta 4.6.

La ”similaridad de las actividades“ se refiere a obtener un solo valor que representa dichasimilaridad, para realizar ese calculo se requiere la actividad actual del colaborador observado


y del observador. La similaridad puede tomar alguno de los siguientes valores: muy similares,similares, mas o menos similar, poco similar, muy poco similar y no similar.

La variable ”objetos compartidos“ en uso, debe contener el objeto que esta usando el obser-vado y los que esta utilizando el observador. La variable dispositivos en uso debe contener tantoel hardware como el software del dispositivo en uso del observador como del observado, con lafinalidad de encontrar los dispositivos disponibles para ejecutar los medios de comunicacion.

La variable contextual ”disponibilidad“ solo es requerida para calcular el medio de contacto,dicha variable contiene unos de los siguientes estados: ocupado, accesible y alcanzable si

es posible

La variable ”preferencias“ del colaborador solo involucra las del colaborador observado, lacuales fueron previamente establecidas por el o por algun mecanismo del sistema.

Proceso de disponibilidad y medios de contacto

Los medios de contacto disponibles en este caso de estudio corresponden a: mensajerıa in-stantanea, video conferencia, voz, y anotaciones privadas.

La siguiente lista de eventos muestra el la manera en que la herramienta puede adaptarse acambios contextuales

1. El colaborador prefiere que el espacio de trabajo determine su disponibilidad y

medio de contacto. En este caso el colaborador omite abrir la ventana de disponibilidad,lo cual indica al espacio de trabajo determinar automaticamente esta.

2. Un colaborador coloca su cursor en la foto de otro colaborador. En consecuencia,la barra de colaboradores despliega varios widgets que muestran la disponibilidad y losmedios de contacto del colaborador observado (cf. Figuras 4.11 y 4.12).

3. El colaborador observador selecciona un medio de contacto del colaborador

observado. Despues de seleccionar el medio de contacto, el respectivo medio de contactoes ejecutado para ser usado por ambos colaboradores.

4.7 Escenario 5: Ocultar informacion

El objetivo de esta propuesta es ocultar informacion de manera automatica ante la presenciade una persona ajena al grupo de colaboracion

Capıtulo 4 109

4.7.1 Preambulo

Frecuentemente la cobertura del servicio de Internet se va incrementando, dicho incremento hapermitido que los usuarios de ese servicio puedan comunicarse facilmente. Dentro del grupo deestos beneficiarios se encuentran los usuarios de los sistemas cooperativos. Gracias a la cober-tura de Internet y a los dispositivos moviles, tales como PC portatiles o tablets, los colaboradorespueden trabajar fuera de sus oficinas.

El problema de trabajar fuera de las oficinas es que los colaboradores pueden acceder a lainformacion confidencial, desde cualquier lugar, e.g., salones de juntas o bibliotecas. Dichainformacion puede ser visualizada por cualquier persona que se acerque al dispositivo. En estecaso el sistema debe interrumpir su funcionamiento de tal forma que oculte el trabajo realizadohasta el momento, i.e., si la informacion esta desplegada, el sistema debera cambiarla por otrainformacion. Otra consecuencia resultante a partir de que una persona ajena se acerque aldispositivo es la interrupcion de la comunicacion.


Supongamos que una empresa de desarrollo de software recibio un reporte de un error graveen un sistema de administracion que ellos desarrollaron. Dada la gravedad del problema, laempresa de desarrollo lanzo una convocatoria a todos sus desarrolladores con la finalidad deencontrar y proponer una solucion a dicho error de software. Por su parte, dicha empresapremiara al grupo que resuelva el problema.

Un grupo de colaboradores, compuesto por Sandy, Alice e Isaac, encontraron el problema en elsoftware. Ası que ellos decidieron hacer un documento explicando tanto los errores encontradosası como la solucion propuesta mediante diagramas de clases y diagramas de estado. Para laredaccion del documento usan un editor cooperativo.

Despues de que el grupo decide el contenido del reporte, ellos se reparten la redaccion deldocumento de la forma siguiente: Sandy tiene asignada la tarea de escribir los errores encon-trados; Isaac debe hacer y describir los diagramas de clase, y Alice tiene que hacer y redactarlos diagramas de estado.

Debido a que el grupo de colaboradores paso mucho tiempo en una oficina buscando lasolucion; ellos deciden trabajar de manera distribuida en la redaccion del documento. Sandyse retira de la oficina, en donde estaban trabajando, para salir a comer en el comedor de laempresa. Ella decide empezar a trabajar en la redaccion del documento mientras espera quele entreguen su comida. Cuando ella va a la mitad de la redaccion le surgen dudas de loserrores encontrados en el software, ası que ella decide entablar una comunicacion con el restodel grupo por medio de la mensajerıa instantanea, la cual forma parte del editor. Mientras elgrupo de trabajo esta participando en la conversacion, Sandy puede ver en su pantalla tanto eldocumento que estan generando ası como la conversacion del grupo. Dentro de la conversacion,


Sandy hace una pregunta al resto del equipo.

Poco tiempo despues de iniciada la comunicacion, un programador ajeno al equipo se acercaa platicar con Sandy. Dicho programador sabe que el equipo de ella ha encontrado tantoel error como la solucion al problema de software, por tal motivo el decide acercarse a lacomputadora portatil de ella para intentar leer tanto el reporte como su conversacion con elequipo. Tan pronto el programador se acerca a la computadora, el sistema del editor detectaque una persona ajena al grupo esta observando de frente la pantalla de la computadora deSandy. Como consecuencia el sistema oculta tanto el reporte como la conversacion que ellalleva a cabo.

Por otro lado, Alice responde a la pregunta generada por Sandy; pero observa que Sandy noresponde a la explicacion dada. De repente Alice nota que la foto de Sandy cambio de color.Cuando Alice ubica su cursor del raton sobre la foto de Sandy, el sistema muestra un mensajeindicando que una persona ajena al grupo esta observando la pantalla de Sandy. Por tal motivoella no puede observar los mensajes enviados ni las actualizaciones, ası como tampoco puededesarrollar sus actividades.


Este escenario solo se adapta a la dimension entorno compartido, la cual pertenece al con-texto de uso de los sistemas cooperativos. Tal adaptacion se logra cuando se detecta unapersona, ajena al grupo de trabajo, cerca de un despliegue de informacion confidencial. Otramanera de adaptarse a la dimension mencionada se hace al notificar a los colaboradores involu-crados en la conversacion de Sandy acerca de la presencia de una persona ajena al sistema.

4.8 Escenario 6: Adaptar la informacion

El objetivo de esta propuesta es adaptar la informacion al contexto.

4.8.1 Preambulo

La adaptacion de la informacion se hace considerando:

• tiempo: refiere a recibir/enviar informacion instantaneamente o estableciendo una fecha.Por ejemplo, un grupo de colaboradores necesitan recibir informacion de manera inmedi-ata ya que esta influye en su actividad actual; pero en otras ocasiones, la informacion noes tan urgente como para recibirla de manera inmediata, como en el caso de las reunionesde trabajo;

• rol: determina la informacion a proveer;

Capıtulo 4 111

• actividad: concierne a proveer informacion que enriquezca la actividad actual del colab-orador, e.g., proveer manuales de diagramas de clase a un colaborador que esta haciendodichos diagramas;

• conjunto de plataformas: se refiere a considerar tanto al hardware como software nece-sario para soportar la informacion;

• Tama~no de los archivos: un factor importante que se debe considerar, ya que no valela pena enviar informacion muy grande en un dispositivo con pocas capacidades, e.g.,telefono inteligente;

• ubicacion del colaborador: se refiere a predecir el tipo de informacion que puede serutil para el colaborador considerando su ubicacion actual;

• preferencias sobre la informacion: se refiere a que dada la especificacion del colab-orador puede recibir informacion relacionada.


Supongamos que Sandy, Alice e Isaac estan registrados en el sistema de consultas a pacientes deun hospital, cada uno de ellos tienen los siguientes roles: Isaac es medico cardiologo, mientrasAlice es pasante de medicina y Sandy es enfermera.

Dado que Alice es pasante de medicina, Isaac quiere que ella deduzca el padecimiento decinco pacientes. Ası que Isaac agenda una cita mediante una agenda cooperativa pertenecienteal hospital. En dicha agenda, Isaac establece la fecha (10 de septiembre del ano en curso),la hora (9 am), el asunto (visita a los pacientes de los cuartos 2, 8, 15, 18 y 19), el lugarde reunion (sala comun de medicos) y los participante (en este caso se agrega el mismo y aAlice). Al momento de llenar los campos anteriores y seleccionar el boton crear cita, la agendacooperativa envıa una notificacion a los participantes.

Alice recibe la notificacion de la reunion a traves de su celular. Adjunto a la notificacion, sedespliega un mensaje para que ella confirme o se rechace la cita; en este caso, Alice confirmasu asistencia a la reunion.

Alice acude en la fecha indicada al hospital desde uno hora antes, ya que ella tiene que hacervarios tramites para ingresar al sanatorio. Cuando Alice acude al hospital siempre lleva consigosu IPad, la cual fue previamente registrada en el hospital y actualizada con las aplicaciones quemanejan los medicos de aquel lugar.

Dado que se acordo una cita por medio de una agenda cooperativa, la aplicacion envıa unrecordatorio de la cita una hora antes de la reunion. En dicho recordatorio se puede incluirel envıo de informacion, e.g., los expedientes de los pacientes a revisar, dicho envıo dependedel contexto del colaborador. Analizando el caso de Alice, el sistema provee la informacional detectar lo siguiente: Alice se encuentra dentro del hospital, la cita que tiene con el Dr.


Isaac esta por llevarse a cabo en una hora, ella tiene el rol de medico pasante. En el caso queella no estuviera dentro del hospital, el sistema por cuestiones de seguridad solo proveera unexpediente reducido sin resultados de estudios.

Como Alice se encuentra en el hospital, el sistema envıa por cada paciente a revisar un ex-pediente que tiene anotaciones, e.g., del Dr. Isaac (cardiologo) y del Lic. Edgar (Nutriologo),y estudios medicos del paciente. Dadas las capacidades limitadas del dispositivo de computoque utiliza Alice, iPad, la agenda le envıa los ultimos estudios (desde dos dıas atras), e.g., elec-trocardiograma, ecocardiograma y ergometrıa, dejando de lado los estudios anteriores. Graciasa que la aplicacion provee los expedientes a los asistentes a la reunion, Alice empieza a revisarcada uno para estar mas involucrada.

Por otro lado, el Dr. Isaac se encuentra en su oficina usando su computadora de escritorio,ası que la informacion que le llega a dicho dispositivo es diferente que la de Alice. Isaacrecibe los expedientes en una version reducida porque el establecio dentro de sus preferenciasdicha accion. Isaac decide dicha preferencia por dos razones: 1) el puede ingresar al sistema encualquier momento para ver los expedientes completos, y 2) el visita a diario a dichos pacientes.El contenido de los expedientes que recibe el Dr. Isaac es el siguiente: las anotaciones de colegasde los dos ultimos dıas, ası como los analisis y estudios de una semana anterior a la fecha ylos signos vitales tomados desde la noche anterior. Al momento de que el Dr. Isaac sale de suoficina lleva consigo su iPad e ingresa al sistema del hospital desde el dispositivo mencionado.

Una vez que Isaac y Alice se reunen, ellos empiezan su recorrido por las patologıas mascomunes, en este caso por el paciente del cuarto 18. Al ingresar al cuarto, el sistema delhospital detecta la presencia de ambos en dicho cuarto; en consecuencia el sistema le proponeal Dr. Isaac delegar algunas responsabilidades a Alice, pero el declinaba la sugerencia ya queel piensa que ella necesitaba practicar mas.

Otra accion por parte del sistema es desplegar en ambas iPad’s el expediente del enfermo delcuarto dieciocho. Para Isaac es normal tener el expediente del paciente la que visita; en cambio,Alice se sorprende porque ella tenıa previamente a la vista el expediente del paciente del cuartodos, puesto que ella penso el recorrido en un orden ascendente. Tanto Alice como Isaac puedenver los resultados de los estudios clınicos. Terminando la visita, el Dr. Isaac agrega anotacionesy modifica la dosis de medicamento, a consecuencia de la mejora del paciente, en el expedientedel enfermo. Alice puede ver a traves de su iPad la serie de pasos que el Dr. Isaac hace almomento de modificar el expediente.

Al instante que la dosis es modificada, el sistema del hospital actualiza la informacion enla base de datos y al personal que atiende al paciente de la cama 18, e.g., la nueva dosis demedicamento se notifica a la enfermera Sandy y la mejora en la salud del paciente se notificaal nutriologo. La actualizacion de la dosis es de manera inmediata ya es esta es de vitalimportancia debido a que una dosis no apropiada puede tener consecuencias fatales en la saluddel paciente.

En las visitas a los cuartos 8 y 19, Alice continua dando sugerencias verbales y observando

Capıtulo 4 113

como el doctor responsable manipula el sistema. Cuando ambos llegan al cuarto 15, el Dr. Isaacdecide que Alice puede empezar a participar en las anotaciones dentro del sistema mediante lassugerencias del sistema. Por tal motivo, ambos tienen derechos de modificar el expediente dedicho paciente.

Finalmente, ellos acuden al cuarto dos en donde la enfermera Sandy esta tomando los signosvitales del paciente del cuarto. Cuando ellos ingresas al cuarto, la informacion de los signosvitales es actualizada inmediatamente a los iPad’s de Alice e Isaac. Al momento que el sistemadetecta que ambos estan en el cuarto, el sistema propone dos opciones: 1) delegar algunasresponsabilidades a Alice o 2) usar la computadora tactil que se encuentra sobre la pared.Ambas opciones solo son desplegadas al Dr. Isaac pues el tiene un rol de mayor jerarquıa que elrol de Alice. Isaac accede a las dos opciones, por tal motivo Alice puede modificar el expedientebajo la supervision del doctor, dicha supervision es permitida desde su iPad. Por otro lado, elsistema despliega todas las ecocardiogramas y electrocardiogramas en la computadora tactil,ya que es muy usual dicha preferencia. Mientras que las iPads solo contienen las anotacionesmedicas.

Al terminar las visitas y cada uno seguir con otras actividades, el sistema no permite queAlice consulte los expedientes de los pacientes visitados; en cambio, el Dr. Isaac tiene accesototal en cualquier momento, mientras el se ubique dentro del hospital. En otros lugares, el Dr.Isaac no puede ver informacion restringida, e.g., anotaciones del nutrılago.


Este escenario aborda todas las dimensiones del contexto de uso de los sistemas cooperativos. Laadaptacion al grupo de colaboradores se implementa al proveer la informacion relacionada alos roles, al respetar los grupos estratificados (Isaac tiene el control de permitir la intervencionde Alice dentro del sistema del hospital) y las preferencias de los usuarios (Isaac decidio que elsistema le provea de informacion actual, a lo mas con dos dıas de anterioridad).

La adaptacion al conjunto de plataformas se presenta al momento de sugerir usar lapantalla tactil cuando estan en un cuarto que tiene dicha pantalla. Tambien se puede ver estadimension que ha sido llevada a cabo cuando el sistema provee solo la informacion mas actuala Alice, dadas las caracterısticas de su dispositivo.

La adaptacion al entorno compartido se aprecia en este escenario, ya que se considera, ellugar (proveer la informacion solo cuando los colaboradores esten dentro del hospital, ası comomostrar en pantalla el expediente del paciente que estan actualmente visitando) y el tiempo(proveer la informacion una hora antes de la reunion).


4.8.3 Herramienta administrador de contenidos vıa NFC

Esta aplicacion nos permite facilitar a un grupo de colaboradores la informacion que se va atratar en una reunion previamente planificada. Dicha informacion se refiere al objetivo de lareunion, los temas a tratar y los archivos relevantes a la misma. Al entrar al lugar de reunion yacercar su dispositivo movil a la etiqueta NFC asociada a dicho lugar, los colaboradores recibenautomaticamente toda la informacion sobre la reunion y los archivos que se discutiran durantela misma.

Esta aplicacion fue desarrollada en colaboracion de un alumno de maestrıa[Romero et al., 2013].


Los requerimientos funcionales del administrador de contenidos vıa NFC se presentan a con-tinuacion:

1. Permitir que un colaborador ingrese la informacion relacionada a una reunion y suba aun servidor de contenidos, los archivos que son relevantes a la misma.

2. Permitir que un colaborador pueda grabar la informacion relacionada a una reunion enuna etiqueta NFC.

3. Permitir que un colaborador, al acercar su dispositivo a una etiqueta NFC, inicie au-tomaticamente su sesion y reciba en su dispositivo la informacion referente a una reunion.

4. La aplicacion debe ejecutarse automaticamente cuando un colaborador inicie sesion pormedio de una etiqueta NFC y haya informacion sobre una reunion en la etiqueta.

5. Adaptar la interfaz de usuario de acuerdo a la informacion recibida, e.g., la interfazmuestra la lista de puntos a tratar en la reunion y la informacion adicional correspondientea cada uno de ellos.

6. Detectar los tipos de formato de documentos soportados por las herramientas instaladasen el dispositivo.

7. Detectar los tipos de formato de documentos soportados por las herramientas instaladasen el dispositivo.

8. Iniciar la descarga de los documentos que es necesario revisar durante una reunion. Du-rante la solicitud de los documentos, se debe indicar que tipos de formato de documentosson soportados, de tal manera que los documentos a descargar sean en un formato sopor-tado.

Capıtulo 4 115

9. Mostrar en la interfaz de usuario de la aplicacion un ıcono que represente el documentodescargado y permitir abrir dicho documento al hacer clic sobre su ıcono.

Los requerimientos no funcionales del administrador de contenidos vıa NFC se listan a con-tinuacion:

1. Habilitar el adaptador de red inalambrico WiFi, si este se encuentra deshabilitado.

2. Permitir la apertura de los archivos descargados.

3. Garantizar la integridad y consistencia de toda la informacion transferida.

4. No permitir la transmision de la informacion a dispositivos de usuarios que no se encuen-tren registrados.

Interfaz de usuario

La aplicacion lleva a cabo la adaptacion de la informacion recibida, ya que es consciente deotras herramientas para visualizar documentos con las que cuenta el dispositivo. Hace uso deesta informacion al solicitar los documentos al servidor, de manera que solo sean descargadosdocumentos en un formato soportado.

La aplicacion consta de un modulo para leer y uno para grabar las etiquetas. A continuacionse presenta una descripcion sobre dichos modulos:

1. modulo de escritura: es usado para grabar la informacion relacionada a una reunion enla etiqueta, ası como la informacion de archivos subidos al servidor que son relevantes ala misma (cf. Figura 4.13a);

2. modulo de lectura: esta disenado para leer las etiquetas y es ejecutado cada vez que eldispositivo reconoce una etiqueta NFC (cf. Figura 4.13b).

En este aplicacion hacemos uso de la tecnologıa NFC para habilitar otros tipos de comu-nicaciones, e.g., WiFi y para proveedor contenidos digitales. La informacion es grabada enetiquetas NFC por el organizador de la reunion y posteriormente los participantes leen dichainformacion al acercar su dispositivo a la misma etiqueta.

Por otro lado, ademas de identificar lugares con esta tecnologıa tambien es posible identificarobjetos, por lo que la aplicacion provee consciencia de localizacion a grano fino, e.g., un pizarroninteractivo.


(a) Modulo de escritura (b) Modulo de lectura

Figura 4.13: IU del administrador de contenidos

Proceso de interaccion con el administrador de contenidos

Durante el proceso, la aplicacion pasa a traves de tres fases principales, las cuales se describena continuacion:

• Nueva reunion: desde su dispositivo movil, un colaborador ejecuta la aplicacion admi-nistrador de contenidos vıa NFC. Como resultado a esta accion, se muestra el modulo deescritura. En este modulo, se presenta una interfaz de usuario que muestra: 1) un campode texto donde se puede escribir el objetivo de la reunion, 2) un boton y un campo detexto para establecer la hora y la duracion de la reunion, respectivamente, 3) botonespara agregar o eliminar temas a tratar durante la reunion, 4) la lista actual de los temas,junto con los archivos relacionados a cada uno y 5) un boton para grabar la etiqueta. Enla Figura 4.13a se muestra la interfaz de usuario del modulo de escritura de la aplicacion.

• Grabacion de etiqueta: despues de haber ingresado la informacion de la reunion yhaber subido los archivos al servidor, se debe grabar la etiqueta. Para esto, solo necesi-

Capıtulo 4 117

tamos acercar el dispositivo a la etiqueta y seleccionar la opcion “Grabar etiqueta” de lainterfaz de usuario.

• Adaptacion de informacion (lectura de etiqueta): cuando un usuario “toca” algunade las etiquetas NFC grabadas con el modulo de escritura de la aplicacion, el dispositivolee la informacion almacenada en la etiqueta y tienen lugar los siguientes eventos: 1) severifica el estado de la conexion WiFi, si esta deshabilitado el adaptador, se habilita y setrata de conectar a un punto de acceso, 2) se inicia automaticamente la sesion del usuario,3) se ejecuta el modulo de lectura de la aplicacion en el dispositivo movil y 4) se muestra,ya sea la lista de reuniones planificadas o si hay una reunion en curso. Si el usuario eligeparticipar en la proxima reunion o en la reunion en curso, la interfaz de usuario de laaplicacion es adaptada con la informacion sobre la reunion, i.e. se muestra la lista depuntos a tratar en la reunion, el objetivo de la reunion y los archivos que son relevantesa la misma. En caso de que el usuario decida no participar, su sesion es finalizada. Enla figura 4.13b se muestra la interfaz de usuario del modulo de lectura de la aplicacion,donde se muestra la informacion sobre la reunion en curso.

Los archivos que es necesario revisar durante la reunion no son almacenados en las etiquetasNFC, debido a las limitaciones de almacenamiento de dichas etiquetas. Por tal motivo, sesolicita al servidor la descarga de los mismos por medio de Wi-Fi. Previamente, la aplicacionidentifica que tipos de formatos de documento son soportados por las herramientas con lasque cuenta el dispositivo. Por lo tanto, durante la solicitud de descarga de un documento, seindican los formatos de archivo soportados por el dispositivo, de tal manera que el documentoa descargar sea en un formato soportado (si esta disponible). Al finalizar la descarga, en lainterfaz de usuario de la aplicacion, se muestran junto a cada tema de la reunion, los documentosdescargados asociados a cada uno. Finalmente, por medio de un clic sobre cada elemento sepuede visualizar el contenido del documento.

Con el fin de mostrar la manera en que el administrador de contenidos puede adaptarse a loscambios contextuales, se describe una lista de eventos que provocan adaptacion.

1. Un colaborador ingresa a una sala de juntas y acerca su dispositivo (a una distancia de3 cm o menos) a una etiqueta NFC: se inicia automaticamente la sesion del usuario, seejecuta la aplicacion administrador de contenidos vıa NFC en su dispositivo movil y laetiqueta transfiere al dispositivo del usuario la informacion referente a una reunion. Lainterfaz de usuario de la aplicacion es adaptada de acuerdo a la informacion recibida, i.e.la interfaz de usuario muestra la lista de puntos a tratar en la reunion y la informacionadicional correspondiente a cada uno de ellos. Se inicia la descarga de los documentosque es necesario revisar durante la reunion.

2. La aplicacion detecta que tipos de formatos de documento son soportados por las aplica-ciones con las que cuenta el dispositivo: durante la solicitud de descarga de un documentodel servidor se indican los formatos de archivo soportados por el dispositivo, de tal maneraque el documento a descargar sea en un formato soportado (si esta disponible).


3. Termina la descarga de los documentos que es necesario revisar durante la reunion: enla interfaz de usuario de la aplicacion se muestra un ıcono que representa el documentodescargado y por medio de un clic sobre dicho ıcono se puede abrir el documento paraver su contenido.

4.9 Escenario 7: Uso de diferentes modalidades en la

notificacion

El objetivo es proveer a las notificaciones de diversas modalidades para que dichas avisos seadapten al contexto.

4.9.1 Preambulo

La modalidad nos puede permitir dar a conocer la llegada de informacion de diferentes formasdependiendo del tipo de informacion a notificar, el lugar en donde se encuentra ubicados loscolaboradores e incluso las personas a nuestro alrededor. Las notificaciones multi-modales masusadas en los celulares son por: sonidos, cuadros de texto o vibracion.

En un ambiente colaborativo es fundamental informar sobre eventos importantes para elgrupo, e.g., cambio de medicamento a un paciente. La modalidad a usarse para notificar lainformacion debe adaptarse dependiendo varios parametros, los cuales son los siguientes:

• la relevancia de la informacion, e.g., es mas importante notificar a una enfermera el cambiode medicamento de un paciente hospitalizado que recibir la notificacion de un dispositivocercano a la enfermera que permite hacer video-llamadas;

• la actividad del colaborador que origina la notificacion y la del colaborador que recibe lanotificacion es importantes;

• el lugar fısico en donde se encuentra el receptor de la notificacion.


Un grupo de colaboradores integrado por Sandy, Alice, Isaac son parte de un equipo de desar-rollo de software de una empresa renombrada. Sandy y Alice estan exponiendo a los clienteslos avances del proyecto. Mientras tanto, Isaac esta terminando una actividad, la cual tenıauna fecha lımite caducada, que no podıan resolver. Dicha actividad es importante, ya que esparte de los avances a presentar frente a los clientes.

Capıtulo 4 119

El sistema informa mediante notificaciones a los miembros del equipo acerca de las modifi-caciones y las actividades concluidas en las que estan participando.

Antes de emitir la notificacion, el sistema determina el modo de la notificacion considerandolas siguientes caracterısticas: 1) la actividad actual de Alice y Sandy, cuya actividad es laexposicion de los avances del proyecto, 2) las colaboradoras se encuentran en una sala de juntascon personas ajenas al proyecto, 3) la actividad concluida es de importancia para ellas, 4) losdispositivos que estan usando los colaboradores, en este caso cada uno de ellos tiene un telefonocelular, ası como dos computadoras portatiles, una de ellas la usa Isaac, mientras que la otraes usada por Alice y Sandy.

En consecuencia, el sistema desvıa la notificacion textual hacia el telefono celular de ambascolaboradoras usando la vibracion de los celulares y la emision de un sonido en un nivel apenasperceptible para avisarles de la llegada de una notificacion. Mientras Alice continua explicando,Sandy decide leer la notificacion, ya que noto que tanto ella como Alice recibieron una notifi-cacion al mismo tiempo. Dicha noticia informa de la conclusion de la actividad pendiente, lacual puede ser mostrada por completo al cliente.

El sistema notifica a Isaac que sus colegas han terminado la exposicion mediante una mensajetextual en la computadora. La notificacion no emite sonido alguno y solo despliega en la parteinferior derecha de la pantalla un recuadro que contiene el anuncio. El sistema notifica de estemodo a Isaac considerando que tiene en uso una computadora, que esta en su oficina y que laactividad de el no es de gran importancia dada la fecha lımite de la actividad.

Isaac quiere saber sobre los resultados de la presentacion con los clientes, por tal motivo elhace una reunion en su oficina mediante una agenda cooperativa. El establece el lugar de reunionsu oficina. Por tal motivo, la agenda informa a Sandy y Alice de dicha reunion de maneratextual, mediante sus telefonos celulares. En esta ocasion, el sistema utiliza nuevamente lavibracion del celular ademas de aumentar el timbre de la notificacion ya que ellas temporalmenteno estan desarrollando una actividad y se encuentran en los pasillos del edificio.

Despues de la reunion con Isaac, las colaboradoras se dirigen cada una a sus oficinas paracontinuar trabajando en las actividades asignadas. Sandy se encarga de los diagramas de clase,ası que ella no requiere ni recibir las notificaciones de actualizacion del diagrama de estado nique se realicen automaticamente las actualizaciones de dichos diagramas (suponiendo que eldispositivo de computo no cuente con los recursos necesarios de espacio en disco duro, pocamemoria RAM o que la intensidad de la senal de Internet sea demasiado debil como parasoportar la transferencia de archivos demasiado grandes), ya que en muchas ocasiones se vuelvelenta su aplicacion en uso. El sistema debe esperar a que Sandy seleccione ver los diagramasde estados para notificarle dichas actualizaciones, ademas el sistema debe revisar si realizo lasactualizaciones de dichos diagramas o tiene que hacer la peticion de las actualizaciones.



Este escenario se adapta a todo contexto de uso de los sistemas cooperativos. Se adapta algrupo de colaboradores ya que verifica la actividad en desarrollo, i.e., envıa la notificaciondel termino de la actividad de Isaac.

Se adapta al conjunto de plataformas porque decide sobre que dispositivo se enviara lanotificacion.

Se adapta al entorno comun porque considera el lugar en donde se encuentra los colabo-radores, ası como la presencia de persona ajenas al grupo de trabajo, de este modo la notificaciones silenciosa.

4.10 Aplicaciones de prueba

Las cinco aplicaciones presentadas en esta seccion han sido implementadas para soportar eltrabajo cooperativo, algunas de ellas permiten tanto el trabajo co-localizado como el distribuido,pero otras solo una de esas dos opciones.

Las herramientas que permiten el trabajo co-localizado como distribuido corresponde a:herramienta de votacion y herramienta editor cooperativo de mapas mentales. Ambas her-ramientas comparten tanto un espacio de trabajo en donde son ejecutada como una sola labarra de colaboradores. Dicha barra se adapta dependiendo del modo de trabajo.

Las herramientas que solo soportan el trabajo distribuido corresponden a la herramientasugerencia proactiva y la herramienta de disponibilidad y medios de contacto. La herramientasugerencia proactiva permite ejecutar tres aplicaciones y crear ligas entre objetos compartidos.La herramienta barra disponibilidad y medios de contacto permiten adaptar dichos compo-nentes, disponibilidad y medios de contacto, considerando las actividades de los colaboradoresinvolucrados, i.e., el colaborador que desea saber la disponibilidad de otro colaborador.

La herramienta administrador de contenidos vıa NFC solo permite el trabajo co-localizado.Dicha herramienta provee documentos relacionados a una reunion, considerando la fecha de lareunion.

4.10.1 Herramienta de votacion

Esta aplicacion intenta facilitar y agilizar el proceso de una sesion de votacion, permitiendo alos votantes ejercer su voto de manera electronica mediante sus dispositivos moviles, ya sea quese encuentren en el lugar de votacion (colocalizados) o en un cualquier otro lugar (distribuidos).

Esta aplicacion fue desarrollada en colaboracion de un alumno de maestrıa

Capıtulo 4 121

[Romero et al., 2013].


Los requerimientos funcionales y no funcionales de esta aplicacion seran tratados en esta seccion.Los requerimientos funcionales se describe a continuacion:

1. Identificar y asignar el rol a cada usuario con base al tipo de dispositivo desde el cualacceden a la aplicacion.

2. Adaptar su IU de acuerdo al rol del usuario y del modo de trabajo co-localizadamente odistribuida.

3. Permitir que el proponente organice una nueva votacion. En particular, se le debe permitirplantear una pregunta hacia el grupo de colaboradores mediante un pizarron interactivo.Determinar las posibles opciones de respuesta para la pregunta, establecer si la votacionpuede ser anonima o no, definir el porcentaje mınimo para hacer valida la votacion yestablecer un tiempo de espera para que los usuarios emitan su voto.

4. Mostrar en los dispositivos moviles tanto de los miembros virtualmente presentes comode los miembros fısicamente presentes, las posibles opciones de respuesta a la pregunta dela votacion, una opcion para abstenerse de votar y, si la votacion lo permite, una opcionpara votar como anonimo.

5. Mostrar en los dispositivos moviles de los miembros virtualmente presentes la preguntaque fue sometida a votacion.

6. Garantizar, siempre que sea posible, la igualdad entre las opciones de voto que aparecenen pantalla, sin favorecer a ninguna.

7. Mostrar en el pizarron interactivo la pregunta sometida a votacion, ası como la infor-macion adicional sobre la misma, i.e., si la votacion puede ser anonima o no, las posiblesopciones de respuesta para la pregunta, el porcentaje mınimo para hacer valida la votaciony el tiempo de espera para que los usuarios emitan su voto.

8. Brindar al proponente la posibilidad de iniciar la votacion, lo cual hara posible que sepuedan recibir y registrar los votos de los electores.

9. Mostrar un tiempo de espera en el pizarron interactivo para que los miembros presentesy virtualmente presentes emitan su voto.

10. Solicitar al votante la confirmacion del voto.

11. Contabilizar los votos de los usuarios y calcular el porcentaje de votacion.


12. Si no se alcanza el porcentaje mınimo de votacion, la aplicacion debe mostrar opcionespara: 1) validar la votacion con el porcentaje actual de votacion, 2) posponer la votaciono 3) cancelar la votacion.

13. Si se alcanzo el porcentaje mınimo de votacion o se valido la votacion manualmente, laaplicacion debe mostrar los resultados de la votacion en el pizarron interactivo y enviarlos resultados a los dispositivos moviles de los miembros virtualmente presentes.

14. Ser capaz de recuperar una sesion de votacion que ha sido establecida como pospuesta.

15. Eliminar toda la informacion de una sesion de votacion establecida como cancelada.

16. Ser capaz de mostrar los resultados de una sesion de votacion establecida como valida.

Los requerimientos no funcionales en la herramienta de votacion se muestra a continuacion:

1. El almacenamiento del voto debe realizarse de manera tal que garantice la privacidad delvoto. No se podra tener acceso a los votos almacenados antes de que se produzca el cierrede la votacion.

2. La informacion se debe transmitir de forma que se garantice la integridad y autenticidadde la misma.


La herramienta de votacion provee un conjunto de interfaces de usuario para soportar unavotacion electronica. Los miembros pueden estar reunidos en una area comun o distribuidos, ohıbridos, i.e., algunos pueden estar reunidos y otros distribuidos. Dicha herramienta explora lamanera en que se debe presentar la informacion para los colaboradores distribuidos (cf. Figura4.14b) o co-localizados (cf. Figura 4.14a). En el caso de los colaboradores co-localizados, ellosveran en sus dispositivos personales solo las opciones que pueden seleccionar, ya que dichosintegrantes estan reunidos en un sala de juntas en donde se esta proyectando el tıtulo; encambio, los colaboradores distribuidos necesitan saber el tıtulo de la votacion ası como conocerlos participantes que se encuentran reunidos fısicamente, virtualmente y los ausentes.

Este herramienta despliega una ventana que permite genera el tıtulo de la votacion, el tiempode espera para que los votantes emitan su voto, los posibles candidatos, el porcentaje mınimopara hacer valida la votacion, ası como permitir que los colaboradores voten de manera anonimao abstenerse de votar (cf. Figura 4.15).

Despues de emitida la votacion, los resultados incluyen el porcentaje obtenido por cadacandidato, ası como los nombre de las personas que votaron por cada uno; pero no seranmostrados los nombres de las personas que decidieron votar de manera anonima. Las interfacesde usuario seran diferentes dependiendo de la ubicacion de los colaboradores, e.g., los colabo-radores co-localizados podran ver los resultados en el proyector (cf. Figura 4.16b). En cambio,

Capıtulo 4 123

(a) Vistas para los votantes colocalizadoen sus dispositivos moviles

(b) Vistas para los votantes distribuidosen sus dispositivos moviles

Figura 4.14: Adaptabilidad de la interfaz de usuario de la herramienta de votacion de acuerdoa la ubicacion del grupo y al rol de votantes

los colaboradores distribuidos veran de diferente forma dichos resultados, e.g., ellos deberanseleccionar la votacion de un candidato para que se despliegue las personas que votaron pordicho candidato (cf. Figura 4.16a).

En la adaptacion al contexto se consideran las siguientes variables contextuales: 1) el roldel colaborador y 2) la configuracion de grupo. Los roles que puede asumir el usuario son: a)proponente, el cual permite a un usuario plantear una pregunta hacia el grupo de colaboradoresy establecer las reglas de la sesion de votacion y b) votante, el cual permite a un usuarioemitir su voto en una sesion de votacion en curso. La configuracion de grupo puede ser: 1)co-localizado (fısicamente presente), cuando el usuario se encuentra en el lugar de votacion y2) distribuido (virtualmente presente), cuando el usuario se encuentra en un lugar diferenteal lugar donde se lleva a cabo la votacion.


Figura 4.15: Opciones establecidas por el colaborador proponente en el pizarron blanco inter-activo

Proceso de votacion

Para llevar a cabo una sesion de votacion, un grupo de colaboradores organiza una reunion enuna sala de juntas que cuenta con una pizarron interactivo. Durante el proceso de votacion laaplicacion pasa a traves de tres fases principales, las cuales se describen a continuacion:

• Propuesta de votacion: cuando un colaborador pasa a la zona donde se encuentra elpizarron interactivo, su presencia es detectada y se inicia su sesion. Desde el pizarroninteractivo, el colaborador selecciona la herramienta de votacion, la cual le otorga el rol deproponente. Mediante dicho rol, el colaborador plantea hacia el grupo de colaboradoresla pregunta a votacion y establece las reglas de la misma. En la figura 4.15 se muestra lainterfaz de usuario con las opciones disponibles para el proponente.

• Votacion: una vez que el proponente ha iniciado la votacion, los usuarios reciben en susdispositivos una notificacion de votacion. Al seleccionar dicha notificacion la aplicacionse ejecutara automaticamente mostrando una interfaz de usuario adaptada de acuerdoal contexto de uso del usuario. Mediante IU el usuario podra emitir su voto y este seraenviado al servidor. En la figura 4.14a se muestra la interfaz de usuario adaptada paralos votantes que se encuentran co-localizados y en la figura 4.14b la interfaz de usuariopara los votantes que se encuentran distribuidos.

• Conteo y publicacion de resultados: despues de que el tiempo de espera ha finalizado,la aplicacion lleva a cabo el conteo de votos. Si el porcentaje de votacion fue alcanzado,los resultados seran mostrados en el pizarron interactivo y enviados a los dispositivos

Capıtulo 4 125

(a) Resultados mostrados a losvotantes distribuidos

(b) Resultados mostrados a los votantes co-localizados

Figura 4.16: Adaptabilidad de los resultados de votacion de acuerdo a la localizacion de losvotantes.


moviles de los usuarios que votaron de manera remota. Por el contrario, si el porcentajemınimo no fue alcanzado, se mostrara un dialogo donde el proponente tendra que elegirsi desea validar con el porcentaje de votacion actual, posponer o cancelar la votacion.En las figuras 4.16b y 4.16a se muestran los resultados de votacion mostrados tanto enel pizarron interactivo como en los dispositivos moviles de los participantes virtualmentepresentes (distribuidos).

Con el fin de mostrar la manera en que la herramienta de votacion puede adaptarse a loscambios contextuales, se describe una lista de eventos que provocan adaptacion.

1. Un proponente inicia una nueva sesion de votacion: cuando un proponente iniciauna nueva sesion de votacion se envıa una notificacion de votacion a los dispositivosmoviles de los participantes presentes y virtualmente presentes, a quienes se les asigna elrol de votante. Ademas, el pizarron interactivo muestra un tiempo de espera para que losparticipantes presentes y virtualmente presentes emitan su voto.

2. Un participante virtualmente presente participa en la sesion de votacion:cuando un participante virtualmente presente selecciona la notificacion de votacion, seejecuta la herramienta de votacion en su dispositivo y adapta su interfaz de usuariomostrando tres listas de conciencia de grupo: 1) ausentes, 2) virtualmente presentes y 3)fısicamente presentes en la reunion; ademas, muestra la pregunta, sus opciones de res-puesta y su informacion adicional, e.g., si la votacion puede ser anonima o no. Cuandoun participante presiona durante 1 o 2 segundos una de las opciones de respuesta, semuestra un mensaje emergente que proporciona informacion adicional sobre la opcionseleccionada.

3. Un participante fısicamente presente participa en la sesion de votacion: cuandoun participante fısicamente presente selecciona la notificacion de votacion, se ejecuta laherramienta de votacion en su dispositivo y adapta su interfaz de usuario desplegandounicamente las posibles opciones de respuesta para la pregunta actual, y, si es el caso,muestra una opcion para votar como anonimo y un boton de abstencion.

4. Se termina el tiempo de espera para emitir los votos: sı la aplicacion detecta quese alcanzo el porcentaje mınimo establecido de votacion, la votacion es establecida comovalida y se muestran los resultados. En caso de que no se haya alcanzado el porcentajemınimo de votacion, la aplicacion muestra un mensaje de aviso en el pizarron interactivoque proporciona las siguientes opciones: 1) validar la votacion con el porcentaje actualde votacion, 2) posponer la votacion o 3) cancelar la votacion.

5. Una sesion de votacion ha sido validada: cuando termina una sesion de votacion yes validada ya sea de manera manual o automaticamente, se muestran los resultados enel pizarron interactivo y se envıan los resultados de la votacion a los dispositivos movilesde los participantes virtualmente presentes. Esta adaptacion se lleva a cabo con baseen la configuracion grupo, para los participantes fısicamente presentes, no es necesario

Capıtulo 4 127

enviar los resultados de la votacion a sus dispositivos debido a que son mostrados en elpizarron interactivo, a diferencia de los participantes virtualmente presentes los cuales notienen vision de dicho despliegue. Ademas tanto en el pizarron interactivo como en losdispositivos moviles de los participantes virtualmente presentes se visualiza el porcentajede votacion de cada opcion, ası como los participantes que votaron por cada una de ellas.La aplicacion adapta la manera en que se muestran los resultados ocultando algunosdetalles en los dispositivos moviles, debido a las dimensiones de la pantalla de despliegue.

6. Una sesion de votacion ha sido pospuesta: cuando termina una sesion de votaciony es establecida como pendiente, se agrega a la lista de votaciones pospuestas, de dondese podra reanudar en otro momento.

7. Una sesion de votacion ha sido cancelada: cuando termina una sesion de votaciony es establecida como cancelada, se elimina la informacion correspondiente a la misma.

8. Un proponente reanuda una sesion de votacion pospuesta: se envıa una notifi-cacion de votacion a cada dispositivo movil de los participantes presentes y virtualmentepresentes que no han emitido su voto en la votacion actual y se les asigna el rol de votante.De igual manera, el pizarron interactivo muestra un tiempo de espera para que emitansu voto.

4.11 Conclusiones

Puede observarse que existe cierta similitud entre la dimension usuario y grupo de colabo-

radores, en donde la primera pertenece los sistemas mono-usuario y la segunda a los sistemascooperativos. Ambas dimensiones incluyen el perfil, las actividades y los roles; la diferencia rad-ica en que la adaptacion al usuario modifica las necesidades y preferencias de un solo usuario,i.e., solo el sistema de dicho usuario se ve afectado sin modificar los sistemas de los demasusuarios; mientras que la adaptacion al grupo de colaboradores puede modificar el com-portamiento del sistema usado por todos los colaborador, e.g., un usuario puede establecer elmedio de contacto para que sus colegas lo contacten dependiendo su actividad y la plataformadel colaborador contactado y a contactar.

El contexto de uso de los sistemas cooperativos afectan a todos los colaboradores que estanconectados al sistema, e.g., en el escenario 4.3 se permite ligar objetos compartidos, los cualeshan sido creados desde diferentes aplicaciones, mediante referencias HTML; ası como notificara 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 delcontexto de uso de los sistemas cooperativo. Dichas adaptaciones se hacen al grupo de colab-oradores al considerar sus preferencia relacionadas a los medios de adaptacion (cf. Escenario4.6), dependiendo del rol se puede mostrar los iconos relacionados a su rol cf. Escenario 4.4,


informacion necesaria dependiendo de la actividad en curso (cf. Escenario 4.8) o en otras oca-siones ocultar dicha informacion que puede ser confidencial (cf. Escenario 4.7). Otra adaptacional colaborador es presentar notificaciones diferentes modalidades dependiendo de la actividado del entorno en donde se ubica (cf. Escenario 4.9).

Dichos escenario no solo cubren la dimension grupo de colaboradores, tambien cubren aspectode la dimension plataforma, ya que algunos de ellos identifican cuando el grupo de colaboradorestiene un conjunto de dispositivos; por ejemplo: activar el medio de contacto de video-conferenciadependiendo si los colaboradores tienen una camara en uso, de otra manera no vale la penoofrecer el servicio (cf. Escenario 4.6), o permitir usar el disco duro de un colaborador cuandoel dispositivo en uso no tenga suficiente espacio para almacenar la informacion (cf. Escenario4.4).

Ası como estos escenarios cubren aspectos del domino del grupo de colaboradores o delconjunto de plataformas; algunos de ellos se adaptan al entorno comun, e.g., adaptar la IUdependiendo el trabajo co-localizado o distribuido (cf. Escenario 4.5) o el detectar la presenciade una persona no autorizada para ver informacion restringida (cf. Escenario 4.7).

Algunas de las propuesta mencionadas en lo escenarios han sido implementadas en las her-ramientas desarrolladas. Por ejemplo adaptar los iconos dependiendo el rol del colaborador (cf.Herramientas 4.4.3 y 4.3.3), al trabajo co-localizado o distribuido (cf. Herramienta 4.10.1, 4.8.3y 4.4.3).

Capıtulo 5

Diseno del marco XARE

En este capıtulo se describen los disenos horizontal y otro vertical del marco XARE. El disenovertical, que se expplica en la seccion 5.1, expresa el contexto de uso de los sistemas colaborativosmediante diagramas de clases (usando UML) y patrones de diseno para que los desarrolladorespuedan implementar dicho contexto.

Antes de dar a conocer el diseno horizontal, se presenta en la seccion 5.2 los principalesmecanismos que cumplen los objetivos de los escenarios identificados en el capıtulo 4. Todos losmecanismos, que se presentan en dicha seccion, contienen los parametros de entrada necesarios,las clases involucradas, ası como los elementos que son susceptibles a ser modificados.

El diseno horizontal se refiere a las capas del marco de adaptabilidad plastica para sistemascolaborativos, el cual se aborda en la seccion 5.3. El marco XARE propone adaptar los sistemascolaborativos al contexto de uso, considerando los percutores de adaptacion (remodelacion yredistribucion) y la participacion de los colaboradores durante el proceso de adaptacion (meta-interfaz con o sin negociacion), evitando en todo momento la perdida (recuperacion del sistema).

5.1 Diagramas de clases

El modelado del contexto de uso se puede hacer de diversas maneras, e.g., on-tologıas [Ejigu et al., 2007], grafos contextuales [Kouadri and Brezillon, 2004], teorıa de ac-tividad [Kofod-Petersen and Cassens, 2006], logica proposicional de contexto, semantica demodelo local/sistemas multicontexto [Serafini and Bouquet, 2004] y diagramas de clases[Derntl and Hummel, 2005]. Para modelar el contexto de uso de los sistemas colaborativosse eligio los diagramas de clases, ya que estos permiten llevar a cabo la implementacion delcontexto mediante lenguajes de programacion orientado a objetos. Ademas, estos diagramashan sido usados para llevar a cabo modelacion visual de conceptos del mundo real, la cualsirve para reducir la complejidad y la carga cognitiva durante la etapa de diseno de un sistema

129

130 Diseno del marco XARE

[Henricksen et al., 2002, Derntl and Hummel, 2005].

5.1.1 Diagrama de clase del contexto de uso de los sistemas coo-

perativos

Como se menciono, el contexto de uso para los sistemas colaborativos se forma de los ele-mentos grupo de colaboradores, conjunto de plataformas y entorno comun. En lafigura 5.1, el contexto de uso de los sistemas colaborativo ha sido modelado mediante el patronde diseno Decorator, el cual permite definir dinamicamente nuevos contextos de uso (claseContextOfUse) para hacer que los sistemas colaborativos se adapten a cambios contextualessin tener que modificar estos (clase AdaptativeGroupwareSystem). De este modo, es posi-ble que sistemas colaborativos no adaptativos (clase ConcreteGroupwareSystem) se vuelvanconscientes del contexto de uso (clases ContextOfUse 1 ... ContextOfUse n).

Los diferentes contextos de uso pueden incluir todos o algunos de los elementos de adaptacion(grupo de colaboradores, conjunto de plataformas y entorno comun) dependiendode los requerimientos del sistema. De esta manera, este patron provee a los progra-madores con un soporte flexible de desarrollo que les permite enriquecer sus sistemas coope-rativos con capacidades de adaptacion, involucrando algunos o todos los componentes (clasesGroupOfCollaborators, SetOfPlatforms y CommonEnvironment).

La figura 5.1 muestra un grupo de colaboradores que esta compuesto por al menos un colabo-rador (clase GroupOfCollaborators) quien tiene un perfil y varios roles. De acuerdo a Gauchet al., un perfil (clase Profile) permite definir las habilidades y preferencias de una persona[Gauch, et al., 2007]. Las habilidades de un colaborador (clase Skill) se refiere a las capaci-dades 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 conjuntode actividades que definen su responsabilidad y alcances.

Las preferencias de un colaborador (clase Preference) conciernen a la eleccion de opcionesofrecidas por el sistema colaborativo, e.g., su disponibilidad, sus medios de contacto y la formade notificar la informacion. La disponibilidad de un colaborador (clase Availability) puedepasar a traves de los siguientes estados (atributo state): presente o ausente, pero si el colabo-rador esta presente, el puede estar ocupado, accesible, alcanzable si es posible y disponible. Uncolaborador puede simultaneamente mostrar a sus colegas diferentes niveles de disponibilidaddependiendo (cf. Mecanismo disponibilidad en la seccion 5.2.2) de:

• la similaridad (atributo similarity) entre su actividad actual o potencial y la de suscolegas que perciben su estado de disponibilidad;

• la fecha lımite (atributo timeSlot) de su actividad actual.

Como se muestra en la Figura 5.1, una actividad (clase Activity) es un conjunto de acciones

Capıtulo 5 131

AdaptiveGroupwareApplication

+operation()

SetOfPlatforms

ActivitytimeSlot:Integergoal:Stringsort:String

SkilldexterityLevel:Integer

1..*

1..*

Has

Has

Has

Has

Stays

HasSimilarity4

Runs

Runs

WorksWith

1..*

1..*

1..*

1

1..*

1..*

1..*1..*

1..*

*

1..* 1..*

1..*

1..*

ComputerDevice

Availabilitystate:String

Single-user systems

Proposed extension

Cooperative systems

GroupOfCollaborators

1..*

ConcreteGroupwareApplication

+operation()

ContexOfUseAdaptiveGroupwareApplication-application:

-collaborator: GroupOfCollaborators-platform:SetOfPlatforms-environment:CommonEnvironment

+operation()

ContexOfUse_n

+operation()

ContexOfUse_1

+operation()

...

Notification

ImmediateForm PeriodicForm

Comunication

1..*1..*

**SharedObject

Modality

Link

1..*

AbstractObject

Audio

Video Text

Image

Object

Workspace

Sensor

PrivateObject

CollaboratorBar

GroupAwareness

UserInterface

CommonEnvironment

Software HardwareRoleProfile

Collaborator

Preference

Action

ContactMeans

Calculates1..*

1..* 1..*

1..*

1..*

PhysicalPlace

ColocalizedSetting

HybridSettingDistributedSetting

Setting PrivateWorkspaceSharedWorkspace

Figura 5.1: Contexto de uso de los sistemas colaborativos

coherentes (clase Action) sobre un objeto compartido (clase SharedObject) o privado (clasePrivateObject) que tienen un objetivo comun (atributo goal). La similaridad de actividades


es medida en terminos del objeto compartido que esta siendo manipulado por los colaboradoresy sus actividades actuales y potenciales (atributo sortActivity). La similaridad entre lasactividades de dos colaboradores puede tener alguno de los siguientes valores: muy similar,similar, mas o menos similar, poco similar, muy poco similar y no similar (cf. Mecanismo desimilaridad de actividades en la seccion 5.2.1).

La figura 5.1 muestra que el medio de contacto de un colaborador (clase ContactMeans)define el camino por el cual el quiere ser contactado en un momento dado, e.g., video-conferencia,mensajerıa instantanea, correo electronico o voz IP. Ası, cada colaborador puede ser contactadopor varios medios de comunicacion dependiendo de:

1. el hardware y el software (clases Hardware y Software) disponible en su dispositivo actual(clase ComputerDevice) i.e., uno de los que esta utilizando para lograr su actividad encurso, y

2. su estado de disponibilidad (clase Availability) o la similaridad entre sus actividadesactuales o potenciales y las de sus colegas que quieren contactarlo.

Los medios de contacto de un colaborador pueden ser establecidos automaticamente por elsistema colaborativo (cf. Mecanismo medios de contacto en la seccion 5.2.3) pero el usuariotiene la posibilidad de modificarlos.

Un colaborador tiene a su disposicion un espacio de trabajo (clase Workspace) que provee deinterfaces de usuario (clase UserInterface) para interactuar con sus colegas. Ademas, dicho es-pacio proporciona una area de trabajo privada (clase PrivateWorkspace), donde el colaboradorcontribuye con sus aportaciones personales (clase PrivateObject). Tambien, el colaboradorpuede compartir con su grupo de colegas un espacio comun (clase SharedWorkspace), el cualprovee consciencia de grupo (clase GroupAwareness) por medio de una barra de colaboradores(clase CollaboratorBar). Dependiendo del rol actual del colaborador, su espacio de trabajo leprovee aplicaciones colaborativas para facilitar las actividades correspondientes a sus roles (cf.Mecanismo para ocultar, sustituir o mostrar un componente en la seccion 5.2.4).

Una aplicacion colaborativa (clase AdaptiveGroupwareApplication) provee accionesvalidas (clase Action) para crear, modificar, anotar y borrar objetos compartidos (claseSharedObject). Una aplicacion colaborativa puede estar relacionada con otras por mediode sus objetos compartidos (clase Link). Un objeto compartido es implementado siguiendo elpatron de diseno Composite porque nuestro marco pretende soportar el dominio de aplicacionesde edicion colaborativa.

Cada instancia de una aplicacion colaborativa es capaz de notificar (clase Notification)a otras instancias, con la finalidad de que los colaboradores posean la informacion necesariapara su actividad (cf. Figura 5.1). Dicha notificacion puede ser enviada usando diferentesmodalidades (clase Modality), e.g., sonido, vibracion o cuadros de texto, dependiendo tanto dela actividad como de la ubicacion fısica del colaborador. La comunicacion (clase Comunication)entre las instancias de una aplicacion permite recuperar informacion nueva o almacenada.

Capıtulo 5 133

Por medio de sus preferencias (clase Preference), cada colaborador puede expresar no solosus intereses en recibir informacion acerca de sus colegas y enviar informacion propia, sinotambien la manera de ser notificado, i.e., el tipo de informacion, para/de quien, cuando ycomo. Particularmente, el envıo y la recepcion de informacion puede ser de dos formas:

1. instantaneo (clase ImmediateForm), la cual se refiere a notificar la informacion en elmomento justo en que es generada, y

2. periodica (clase PeriodicForm), la cual notifica en un tiempo predefinido.

El entorno comun (clase CommonEnvironment) es donde la colaboracion toma lugar, la cualinvolucra bastantes variables contextuales, e.g., los lugares fısicos (clase PhysicalPlace) endonde los colaboradores estan interactuando. Dicha deteccion se logra mediante sensores (claseSensor) en hardware, e.g., sensores infrarrojos, o por software, e.g., reconocimiento de rostros.Por lo tanto, tres posibles casos:

1. todos los colaboradores estan distribuidos, i.e., cada uno este localizado en un lugardiferente (clase DistributedSetting);

2. todos los colaboradores estan localizados en el mismo lugar (clase ColocalizedSetting);

3. forma mixta (clase HybridSetting), i.e., algunos colaboradores estan colocalizados mien-tras otros estan distribuidos.

Un despliegue multi-dispositivo y multi-usuario implica que cada colaborador puede nosolo tener la posibilidad para interactuar con otros colaboradores, si no tambien utilizar si-multaneamente varios dispositivos para ejecutar sus actividades, e.g., cuando los colaboradoresestan co-localizados (clase ColacalizedSetting), cada colaborador puede tener una com-putadora portatil (clase ComputerDevice), en donde su espacio de trabajo privado (clasePrivateWorkspace) es desplegado, y un telefono inteligente que actua como control remotode un pizarron electronico, donde el espacio de trabajo compartido (clase SharedWorkspace)puede ser visualizado por todos los colaboradores.

Dependiendo de la configuracion del grupo algunos componentes pueden ser desplegados uocultados en la interfaz de usuario. Por ejemplo, si todos los colaboradores estan 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 documentosde texto, imagenes, contenidos de chat y reportes. Nosotros nombramos a dichos artefactoscomo “objeto abstracto” (clase AbstractObject) para referirnos a la informacion electronicaque es utilizada, generada y compartida por los colaboradores. Dicha informacion extiendelos ejemplos anteriores como son: audios (clase Audio), videos (clase Video), imagenes (claseImage), documentos de texto (clase Text) como son: manuales, reportes, artıculos, informacionrelacionada con la comunicacion, tales como conversaciones de texto provenientes de la men-sajerıa instantanea o por mensajes enviados desde un celular.


5.1.2 Diagrama de clases del vigilante

El componente de contexto de uso (clase ContexOfUse) esta provisto de un vigilante (claseWatcher), el cual es responsable de observar las cambios de contexto con el fin de ejecutar lospercutores de adaptacion (clases Remodelation y Redistribution), la granularidad del estadode recuperacion (clase Recovery) y la granularidad de adaptacion (clase Adaptation) ası comode detectar cuando se esta manipulando un objeto compartido (clase Link) de manera implıcitao explicita (cf. Figura 5.2).

MetaUI

Redistribution Adaptation LinkRemodelation

PrivateWorkspaceSharedWorkspace

UpdateUpdate

RunsRunsRuns

Has

Runs

Runs

+WithNegotiation()+WithoutNegotiation()+Plastic()

Watcher

ContexOfUseAdaptiveGroupwareApplication-application:

-collaborator: GroupOfCollaborators-platform:SetOfPlatforms-environment:CommonEnvironment

+operation()

Recovery

Proposed extension

Figura 5.2: Diagrama de clases del observador

Varias de las clases que ejecuta la clase Watcher pueden ofrecer varios tipos de meta-interfaz de usuario (clase MetaUI), los cuales corresponden a: meta-IU con negociacion (metodoWithNegotiation()), meta-IU sin negociacion (metodo WithoutNegotiation()) y meta-IUplastica (metodo Plastic()). Dicha meta-interfaz esta acargo de informar los cambios quedeben ejecutarse en los espacios de trabajo compartido (clase SharedWorkspace) y privado(clase PrivateWorkspace).

Como se menciono en la seccion 2.2 del capıtulo 2, , la redistribucion[Vanderdonckt, et al., 2008] denota: “ La reasignacion de los componentes de la interfazde usuario de una aplicacion a diversos dispositivos de interaccion. Los tipos de redistribucionson los siguientes: 1) de centralizada a centralizada, 2) de centralizada a distribuida, 3) dedistribuida a centralizada y 4) de distribuida a distribuida”.

Capıtulo 5 135

La clase Redistribution tiene como finalidad redistribuir la interfaz de usuario de unaaplicacion colaborativa en un conjunto de dispositivos, los cuales pueden pertenecer a un colab-orador (clase Collaborator) o un grupo de colaboradores. La clase Watcher esta encargadade llamar a la clase Redistribution, cuando detecta alguno de los siguientes cambios:

• Cambio en la forma de trabajo:

– colocalizado (clase ColocalizedSetting), e.g., se reune un grupo para trabajar, oun colaborador se une al equipo colocalizado;

– distribuido (clase DistribuitedSetting), e.g., el grupo co-localizado se separa, perocontinuan trabajando sobre el mismo objeto;

– hıbrido (clase HybridSetting), e.g., sobre un mismo espacio compartido (claseSharedWorkspace) trabajan colaboradores co-localizados y redistribuidos.

• Deteccion de varios dispositivos de computo (clase SetOfPlatforms):

– los colaboradores trabajan sobre un mismo espacio compartido (claseSharedWorkspace) de manera co-localizada; los componentes de dicho espacioseran redistribuidos sobre el conjunto de dispositivos (clase SetOfPlatforms) enuso;

– los colaboradores trabajan sobre su espacio privado (clase PrivateSpace), ya seade manera distribuida y/o co-localizada, cada colaborador podra aplicar la redis-tribucion para configurar su propio espacio privado.

En la seccion 2.2 del capıtulo 2, la remodelacion de la interfaz de usuario[Vanderdonckt, et al., 2008, Coutaz and Calvary, 2008] denota: “Cualquier reconfiguracion dela interfaz de usuario de una aplicacion que sea perceptible al usuario. La reconfiguracion dela interfaz de usuario resulta de la aplicacion de una o mas transformaciones sobre todos oalgunos de los componentes”.

La clase Remodelation permite ocultar, sustituir o agregar componentes en las interfacesde usuario. Los componentes susceptibles a remodelar son los siguientes (cf. seccion de losescenarios 4.2):

• el espacio de trabajo:

– privado de un colaborador dependiendo sus roles (clase Rol), cuando este ingrese ala sesion;

– compartido al detectar a un grupo de colaboradores trabajando colocalizadamente(clase ColocalizedSetting) o distribuidamente (clase DistribuitedSetting);

• la informacion, e.g., ocultar la informacion al detectar una persona ajena al grupo de co-laboradores o mostrar informacion dependiendo del lugar, de la fecha y de las necesidadesdel colaborador;


• los medios de contacto y la disponibilidad del colaborador (clases Availability yContactMeans) dependiendo de quien sea el colaborador observado y observador;

La clase Watcher ejecuta la clase Remodelation al detectar algunos de los siguientes cambiosen el contexto:

• inicio de sesion por parte de un colaborador;

• deteccion del modo de trabajo (distribuido o co-localizado);

• deteccion de una persona ajena al grupo de trabajo, la cual esta muy cerca del area dedespliegue de informacion;

• deteccion de la fecha y hora para enviar informacion relacionada a la actividad de uncolaborador;

• calculo de disponibilidad o medio de contacto.

Como se menciono en la seccion 2.4 del capıtulo 2, la granularidad del estado de recuperacioncaracteriza [Vanderdonckt, et al., 2008]:

“El esfuerzo de los usuarios que deben realizar para continuar su actividad despues de ocurridala adaptacion. Dicha granularidad aborda tres niveles: sesion, tarea y accion fısica”.

La clase Recovery tiene como finalidad almacenar el estado de los espacios de trabajo compar-tidos y/o privado (clases SharedWorkspace y PrivateWorkspace, respectivamente), los cualesincluyen el trabajo en proceso. La clase Watcher ejecuta la clase Recovery antes de llevar acabo la adaptacion al contexto por medio de la redistribucion, la remodelacion o la sugerenciade seguir conversaciones mediante la deteccion de la utilizacion de un objeto compartido.

En la seccion 2.3 del capıtulo 2 se menciono que la granularidad de los componentes de lainterfaz de usuario denota [Vanderdonckt, et al., 2008]:

“La unidad mas pequena de software que puede ser afectada por la remodelacion y/o redis-tribucion, las cuales pueden ser totales o parciales”.

La clase Adaptation tiene como finalidad adaptar la interfaz de usuario, cuando la claseWatcher lanza en ejecucion la remodelacion y/o la redistribucion.

Finalmente, la clase Link tiene como objetivo relacionar una aplicacion con otra por mediode sus objetos compartidos. La clase Watcher ejecutara la clase Link cuando detecta que doso mas colaboradores hacen referencia a un mismo objeto compartido al mismo tiempo. Dichoobjeto esta siendo manipulado por dos aplicaciones diferentes.

Capıtulo 5 137

5.2 Mecanismos del marco XARE

El marco propuesto depende de varios mecanismos que proporcionan los calculos necesariospara la adaptacion al contexto. Algunos de esos calculos se llevan a cabo mediante reglasdifusas.

5.2.1 Mecanismo de similaridad de actividades

Este mecanismo es solicitado por los mecanismos de disponibilidad y el medio de contacto, yaque dichos mecanismos lo requieren para hacer sus propios calculos. La similaridad de activi-dades (cf. Figura 5.3) involucra a un colaborador observado y un observador. Los parametrosnecesarios para calcular la similaridad de actividades corresponden a: 1) las actividades po-tenciales y actuales que estan siendo ejecutadas por dichos colaboradores, y 2) los objetoscompartidos que estan procesando mediante sus acciones.

La similaridad entre las actividades de los colaboradores observado y observador puedentomar los siguientes valores:

1. muy similares, cuando ellos estan llevando a cabo las mismas acciones sobre el mismoobjeto compartido;

2. similares, cuando los colaboradores estan ejecutando las mismas acciones en diferentesobjetos que tienen cierta relacion (e.g., una figura y el correspondiente parrafo que describeesta);

3. mas o menos similares, cuando ellos estan ejecutando las mismas acciones en diferentesobjetos no relacionados (e.g., modificacion de diferentes secciones);

4. poco similares, cuando dos colaboradores estan ejecutando diferentes acciones sobreobjetos relacionados;

5. muy poco similares, cuando ellos estan ejecutando diferentes acciones sobre diferentesobjetos;

6. no similares en cualquier otro caso.

En la tabla 5.1 se ejemplifica la forma de asignar los grados de similaridad entre las actividadesentre el colaborador un y las de sus colegas u1, u2, u3, u4, u5 y u6 toma en cuenta las accionesactuales que estan llevando acabo aquellos colaboradores, ademas de considerar los objetos queestan manipulando por medio de tales acciones. Tambien se esta considerando las accionesy los objetos que son potencialmente accesibles por el colaborador un. De esta forma, elcolaborador un tiene actividades muy similares y similares a las de los colaboradores u1 y u2


GrupoDeColaboradores

ConjuntoDePlataformas

Dispositivo:dispositivo_a

Hardware:hardware

Software:software

Dispositivo:dispositivo_b

Collaborador:observador

evaluar

crear()

tiene

tiene

tiene

tiene

características

características

tiene

tiene

tiene tiene

actividad_a actividad_b

disponibilidad del usuarioobservado

preferencias del usuario observado

similaridad

(observado y

observador)

simila

ridad

(observado y

observador)

tiene

tienetiene

tiene

tiene

Collaborador:observador

Objeto:objeto_a

Objeto:objeto_a

Objeto:objeto_b

Actividad:actividad_a

Actividad:actividad_b

FechaLímite:fechaLímite

Disponibilidad:disponibilidad

Preferencias:preferencias

Acción:acción_a

Action:action_b

Mecanismo:Disponibilidad

Mecanismo:Similaridad

Mecanimo:Medio de contacto

Figura 5.3: Mecanismo para determinar entre dos colaboradores su similaridad de actvidades,la disponibilidad y los medios de contacto

respectivamente durante una sesion de trabajo donde los colaboradores u1 y un estan concu-rrentemente modificando el objeto compartido o, mientras que el colaborador u2 esta modificadoel objeto compartido p, el cual esta relacionado con el objeto o.

Sin embargo, la situacion previamente mencionada puede ser completamente diferente en unasesion subsecuente o incluso en la misma sesion, debido al caracter dinamico del trabajo coope-rativo. Por ejemplo, si el colaborador un empieza a hacer anotaciones en el objeto compartidoq, el cual no esta relacionado con el objeto o ni con el objeto p, mientras los colaboradores u1

y u2 estan haciendo las actividades mencionadas, las actividades del colaborador un pueden noser similares a algunas de los colaboradores u1 y u2.

Capıtulo 5 139

Actividadesun esta modificando elobjeto o

un esta haciendo ano-taciones sobre el objetoq, el cual no esta rela-cionado con p

u1 esta modificando el ob-jeto o

Muy similaresPotencialmente no simi-lares

u2 esta modificando el ob-jeto p, el cual esta rela-cionado con o

SimilaresPotencialmente no simi-lares

u3 esta modificando el ob-jeto q, el cual no esta rela-cionado con o

Mas o menos similaresPotencialmente pocosimilares

u4 esta haciendo anota-cioens sobre el objeto o

Poco similaresPotencialmente mas omenos similares

u5 esta leyendo el objeto p Muy poco similarPotencialmente no simi-lar

u6 esta leyendo el objeto q No similaresPotencialmente pocosimilares

Tabla 5.1: Similaridad entre las actividades de dos colaboradores

Las clases utilizadas en este mecanismo corresponden a: Activity y Action. La primeraclase permite obtener el conjunto de actividades asociados a ambos colaboradores (observadoy observador), ası como hacer el calculo de la similaridad de actividades mediante el metodoHasSimilarity; mientras que la clase Action permite identificar sobre que objeto compartidoestan trabajando dichos colaboradores en ese momento para inferir la actividad en curso.

5.2.2 Mecanismo de disponibilidad de un colaborador

Este mecanismo es responsable de determinar la disponibilidad de los colaboradores, cuyovalor varia de un observador a otro. Un colaborador puede ser percibido como presente oausente durante una sesion de trabajo. En caso de que el colaborador observado este presente,el observador puede percibir subestados, cuyo objetivo es proveer mas detalle acerca de ladisponibilidad del colaborador observado. Ası, cuatro subestados son considerados por este


mecanismo:

1. ocupado: posibilita al colaborador observado a informar que no quiere ser interrumpido;

2. accesible: permite al colaborador observado indicar que, aun si el esta ocupado, puedeser interrumpido si es necesario y tan pronto como el pueda respondera;

3. alcanzable si es posible: el colaborador observado admite que puede ser inte-rrumpido, pero no asegura una rapida respuesta;

4. disponible: permite al colaborador observado ser contactado en cualquier momento.

Al igual que la similaridad de actividades, la disponibilidad se calcula tomando en cuenta lainformacion siguiente del colaborador observado y del observador (cf. Figura 5.3):

1. la similaridad entre las actividades (potencial o actual) del colaborador observado y elobservador, y

2. la fecha lımite de la actual actividad (e.g., distante o cercana) del colaborador observado.

En caso de que la disponibilidad haya sido establecida manualmente por el colaborador obser-vado, este mecanismo tiene que considera las preferencias establecidas por el.

La tabla 5.2 muestra algunos ejemplos de los subestados de disponibilidad de un colabo-rador observado, tal como estos son percibidos por un observador de acuerdo a las condicionesprevias. Cuando el colaborador observado y el observador estan ejecutando actividades muysimilares o similares, el observador puede percibir la disponibilidad del colaborador observadocomo accesible, aun si la fecha lımite de la actividad de este ultimo observado es cercana odistante. En esta situacion, el mecanismo favorece la posibilidad de mantener comunicacioncon el colaborador observado, desde el punto de vista de actividades similares.

Por otro lado, si los colaboradores estan ejecutando actividades mas o menos similares opoco similares, el observador puede percibir la disponibilidad del colaborador observado comoalcanzable si es posible, cuando la fecha lımite de la actividad de este ultimo es cercana;de otra manera su disponibilidad sera accesible cuando la fecha lımite de la actividad seadistante. En el caso de aquellos colaboradores esten ejecutando actividades muy poco similareso diferentes, pero una de las actividades potenciales del observador es similar o muy pocosimilar a la actividad actual del observado, el observador puede percibir la disponibilidad delobservado como alcanzable si es posible, sin importar cuando se termina la actividaddel colaborador observado. En estas situaciones, el mecanismo facilita el contacto entre loscolaboradores, aunque en diferentes grados.

Cuando las actividades actuales tanto del colaborador observado como del observador sonmuy poco similares o no similares, pero sus actividades potenciales son poco similares

Capıtulo 5 141

Disponibilidad del colaborador observado Fecha lımite

Cercano ... Distante

La actividad actual del observador es similar o muy

similar a la del colaborador observadoAccesible Accesible

La actividad actual del observador es mas o menos

similar o poco similar a la del colaborador observado

Accesiblesi es posi-ble

Accesible

La actividad actual del observador es muy poco

similar o no es similar a la del colaborador obser-vado, pero una de sus actividades potenciales es similaro muy similar

Alcanzablesi es posi-ble

Alcanzablesi es posi-ble

La actividad actual del observador es muy poco

similar o no es similar a la del colaborador obser-vado, pero una de sus actividades potenciales es mas o

menos similar o poco similar

OcupadoAlcanzablesi es posi-ble

La actividad actual y las potenciales del colabo-rador observador son muy poco similares o no son

similares a la actividad actual del colaborador obser-vado

Ocupado Ocupado

Tabla 5.2: Estado de disponibilidad del colaborador observado respecto a un colaborador ob-servador

o mas o menos similares en un momento dado, el mecanismo solo facilita el contacto cuandola fecha lımite de la actividad del observador es distante. De otra manera, el colaboradorobservador percibe al observado como ocupado. Finalmente, si el colaborador involucrado notiene en comun actividades actuales o potenciales, el contacto es imposible. Sin embargo,este mecanismo puede ser configurado por cada colaborador para proveer flexibilidad paraser contactado. Por ejemplo, este mecanismo permite al observador tener contacto con elcolaborador observado, cuando la fecha lımite de la actividad actual de este ultimo sea distante.Esta situacion es razonable, ya que ese colaborador observador esta trabajando en el mismoproyecto.

Aun si los subestados de la disponibilidad estan determinados por el mecanismo propuesto,el colaborador observado puede modificarlos cuando el lo requiera.


En consecuencia, este mecanismo usa las clases: Availability y Activity. El mecanismode disponibilidad forma parte de la primera clase, Availability. La clase Activity propor-ciona la similaridad entre las actividades de los colaboradores involucrados, ası como el tiempolımite de la actividad en curso del colaborador observado (cf. atributo timeSlot de la claseAvailability 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 colaboradorespueden contactarlo, e.g., correo electronico, video conferencia y voz. Aunque cada colaboradortiene la libertad de determinar su preferencia por algunos medios de contacto, existe un calculoautomatico para proveer dichos medios de manera automatica. Para dicho calculo se requierenvarios parametros (cf. Figura 5.3), los cuales son los siguientes:

1. los subestados de la disponibilidad de los colaboradores (disponibilidad de un colabo-rador), la cual fue calculada a partir de las actividades que ejecutan sobre un objeto(similaridad de actividades);

2. el medio de contacto preferido del colaborador observado,

3. las caracterısticas de hardware y software de los dispositivos de los colaboradores involu-crados.

Considerando los parametros de entrada del mecanismo de medios de contacto (disponibil-idad, preferencias acerca de los medios de contacto y caracterısticas de los dispositivos) semuestra un ejemplo de como establecer los medios de contacto:

• video-conferencia, voz y mensajerıa instantanea por colegas cuya actividad actual o po-tencial es muy similar o similar;

• anotaciones privadas sobre el texto de colegas cuya actividad actual o potencial es pocosimilar a su actual o potencial actividad, y

• correo electronico de otra manera.

Para todos los medios de contacto, se debe verificar que ambos colaboradores tengan tanto elhardware como el software que soporte dicho servicio; de otra manera, el medio de comunicaionno estara disponible.

Las clases involucradas en este mecanismo corresponde a: ContactMeans, Availability,Hardware y Software. Mediante las dos ultimas clases, Hardware y Software, se obtienen lascaracterısticas de los dispositivos que usan ambos colaboradores, el observado y el observador.

Capıtulo 5 143

La clase Availability permite conocer la disponibilidad del colaborador observado. Final-mente, la clase ContactMeans contiene una lista de medios de contacto asociados al usuarioobservador. Dicha lista de medios de contacto es visualizada por el observador.

5.2.4 Mecanismo de ocultar, sustituir y mostrar componentes

El mecanismo de ocultar, sustituir y mostrar componentes modifica la visibilidad de los compo-nentes, e.g., dependiendo del rol del colaborador se ocultan los iconos de acceso directo a lasaplicaciones o dependiendo del espacio libre en el disco local de un dispositivo se puede ofrecerguardar informacion en otro dispositivo. En el escenario 4.4 se explica mas a detalle los posiblesusos de este mecanismo.

Este mecanismo (cf. Figura 5.4) tiene dos parametros de entrada, los cuales corresponden a

1. el rol del colaborador, y

2. el conjunto de dispositivos disponibles, los cuales incluyen los que pertenecen a los colab-oradores participantes en la sesion o servidores.

Para explicar mejor el mecanismo de la figura 5.4, supongamos un colaborador (A) que tieneasociado un rol, dicho colaborador ingresa a su espacio de trabajo mediante un conjunto dedispositivos (A). El mecanismo debe ocultar o mostrar un componente o un conjunto de compo-nentes dependiendo los posibles roles que puede desempenar el colaborador, ası como el conjuntode dispositivo que esta usando dicho colaborador (dispositivo A). En el caso de componentesque representen una funcionalidad, e.g., ıcono de guardar o imprimir; el mecanismo debe veri-ficar si es posible ofrecer esas funcionalidades o requiera usar otros dispositivos (B), los cualesno pertenecen al colaborador (A). Los componentes susceptibles a ser modificados pertenecenal espacio de trabajo del colaborador (A).

Las clases involucradas en este mecanismo corresponden: Role, ComputerDevice yWorkspace. La clase Role proveera todos los roles asignados a dicho colaborador, mientrasque la clase ComputerDevice proporcionara las caracterısticas de hardware y software de losdispositivos en uso del colaborador, y ademas, cuando sea necesario, proveera las caracterısticasde los dispositivos que pueda usar el colaborador. La clase Workspace reflejara la modificacionde los componentes, ya sea que modifique el espacio de trabajo o la funcionalidades que ofrecenlas aplicaciones, e.g., los iconos ofrecidos por una aplicacion pueden ser ocultados ya que noestan relacionados al rol del colaborador.


ConjuntoDePlataformas

EntornoComún


tieneColaborador:colaborador_a

Rol:rol

tiene

tiene

tiene

tiene tiene

tiene

tiene

modificarComponente()

modificarComponente()

rolActual

Mecanismo:Ocultar/Mostrar

EspacioDeTrabajo:espacioDeTrabajo

AplicacionesCooperativas:aplicacionesCooperativas

Hardware:hardware

Sofware:software

Dispositivo:dispositivo_a

Dispositivo:dispositivo_b

Dispositivosopcionales

Dispositivos personales

Figura 5.4: Mecanismo para ocultar, sustituir o mostrar funcionalidades y/o componentes

5.2.5 Mecanismo de creacion de hiperligas entre los objetos com-

partidos

El mecanismo de creacion de hiperligas permite crear referencias de objetos compartidos entreaplicaciones, con la finalidad de que dichos objeto no pierda su contexto.

El mecanismo Deixis (cf. Figura 5.5), que provee la mensajerıa instantanea, permite a loscolaboradores crear hiperligas entre una palabra clave y un objeto compartido que pertenece aleditor colaborativo. Gracias a la funcionalidad ofrecida por este mecanismo, los colaboradoresno necesitan copiar los parrafos referenciados desde el editor colaborativo hacia la mensajerıainstantanea para referenciar dicho parrafo.

El mecanismo de hiperligas tiene dos parametros de entrada, los cuales son:

1. la seleccion de un objeto compartido desde el editor colaborativo. Dicho objeto se puedereferir a: un tıtulo, un parrafo, una frase, una palabra, una referencia, una figura o una

Capıtulo 5 145


EntornoComún

tiene

tiene

tiene

tiene

tiene

palabra deítica

tiene

tiene

tiene

párrafo

tieneMecanismo:

Deixis

Colaborador:colaborador_a

EspacioDeTrabajo:espacioDeTrabajo

AplicacionesCooperativas:mensajeríaInstantánea

ObjetoCompartido:palabraDeíctica

ObjetoCompartido:párrafo

ReferenciaDeítica:referenciaDeíctica

AplicacionesCooperativas:editorColaborativo

Rol:rol

Figura 5.5: Creacion de hiperligas desde la mensajerıa instantanea

seccion, y

2. la palabra deıctica seleccionada desde la opcion Deixis. Las palabras deıcticas puedencorresponder a alguna de las siguientes: this figure, the next section, this paragraph, thosereferences o here.

En la figura 5.5 se puede observar a un colaborador (colaborador) que esta trabajando ensu espacio de trabajo (espacioDeTrabajo), en donde el esta usando la mensajerıa instantanea(mensajerıaInstantanea) y el editor colaborativo (editorColaborativo). En este caso, el colab-orador crea una hiperliga entre una palabra deıctica (palabraDeıctica) y un parrafo (parrafo)mediante el mecanismo Deixis.

Por otro lado, cuando el colaborador de clic sobre la referencia recibida, la aplicacion demensajerıa instantanea debe mostrar el objeto referenciado a la mitad del area des desplieguedel editor. En el caso de que el objeto referenciado sea un texto, este debe cambiar de color;en cambio, si el objeto referenciado es una imagen, esta debe estar encerrada en un recuadro.Ademas de encerrar la imagen referencia en un recuadro, el espacio de trabajo debe ofrecer


la opcion de crear una copia en el pizarron multi-usuario. Dicha copia contiene un id internodentro del documento origen, ası como el nombre y la ubicacion de dicho documento. Lasmodificaciones realizadas desde el pizarron seran reflejadas automaticamente en el editor detexto.

Las clases involucradas en este mecanismo corresponden a: Link y SharedObject. Las claseLink contiene el mecanismo Deixis, mientras que la clase SharedObject contiene todos losposibles objetos susceptibles a ser referenciados.

5.2.6 Mecanismo de proximidad logica

La proximidad logica entre los colaboradores es medida en terminos de la relativa cercanıa entrelos objetos compartidos que se estan manipulando en el espacio de trabajo compartido.

En una sesion colaborativa, los colaboradores pueden estar creando, modificando, visual-izando y/o anotando en los objetos compartidos que pertenecen a un documento de texto ode imagen. Ambos documentos siguen una estructura de arbol, la cual permite mostrar lagranularidad de dichos objetos (cf. Figura 5.6).

Los objetos compartidos tales como documentos de texto o proyectos de imagenes puedenser representados mediante arboles, cuyo nodo raız es el nombre del documento (el contenedorde texto e imagenes) o el proyecto (el contenedor de imagenes) en cuestion.

Mediante la figura 5.6a podemos observar que la granularidad de documentos de texto queva desde el documento completo hasta el nivel palabra. La estructura de la figura 5.6a muestraun documento de texto, cuyo nombre es Di, el cual tiene secciones (S) que pueden contener:parrafos (P ), imagenes (I) o subsecciones (U). A su vez, dichas subsecciones tambien puedenalojar: parrafos e imagenes. Los parrafos se componen de palabras (A).

En el caso de las imagenes, la granularidad va desde el nivel proyecto hasta nivel de figuras,las cuales puede ser una lınea, un cırculo, un rectangulo y un cuadrado. La figura 5.6b muestraun proyecto de imagenes vectoriales, cuyo nombre es (Pi), el cual contiene hojas (H) que sirvende lienzos para el dibujo. Dichas hojas contienen imagenes (I) que estan compuestas por figuras(F ) basicas.

En este mecanismo se propone definir grados de proximidad logica en el espacio de trabajocompartido de la siguiente manera:

1. muy cercanos, cuando los colaboradores estan accediendo al mismo objeto compartido,a pesar de sus respectivos tipos de acceso (e.g., leer, escribir o anotar);

2. mas o menos cercano, cuando los colaboradores estan procesando diferentes objetoscompartidos (e.g., subsecciones), las cuales tienen el mismo padre (e.g., una seccion);

Capıtulo 5 147

Di

DiS1 ...

Documento(D)Sección (S) Palabra ( )

Párrafo (P)A

Subsección (U) Imagen (I)i-ésimo objeto compartidon-ésimo objeto compartido

DiSn

DiS1InDiS1Pn ... DiSnInDiSnPn ...DiS1Un... DiSnUn ...

DiS1UnIn DiSnUnInDiS1UnPn DiS1PnAn

DiS1UnPnAn DiSnUnPnAn

DiSnPnAnDiSnUnPn

(a) Visualizacion de un documento de texto

Pi

PiH1 ...

PiH1I1... PiHiI1... PiHnI1...PiH1In PiHiIn PiHnIn

PiHi ...

Proyecto (Di) Figura ( )Hoja (H)Imagen (I)

Fi-ésimo objeto compartidon-ésimo objeto compartido

PnHn

PiH1I1Fn PiH1InFn PiHiI1Fn PiHiInFn

(b) Visualizacion de un proyecto de imagenes

Figura 5.6: Visualizacion de documentos en forma de arbol

3. potencialmente mas cercano cuando un colaborador trabaja sobre un objeto compar-tido (e.g., subsecciones), el cual es potencial para otro colaborador, cuyos objetos com-parten el mismo padre (e.g., una seccion);

4. potencialmente remoto, cuando los colaboradores estan accediendo a diferentes objetoscompartidos que no comparten el mismo padre, pero alguno de sus objetos potenciales(e.g., subsecciones) tienen el mismo padre (e.g., una seccion);

5. remoto de otra manera.

La tabla 5.3 ilustra los diferentes grados de proximidad logica entre el colaborador un y suscolegas u1, u2 y u3. En este mecanismo (cf. Figura 5.7), los parametros de entrada corresponden


a: 1) los objetos actuales, los cuales ellos estan accediendo, y 2) los objetos potenciales que sonlos objetos que estan al alcance de los colaborador (en este ejemplo, el colaborador un). Tanto elobjeto potencial como el actual pueden ser determinados desde la actividad actual y potencialdel colaborador, respectivamente. Ası, aunque el colaborador un y u3 esten remotamente en elespacio compartido al manipular los objetos o y q respectivamente, la posibilidad de accederotros objetos compartidos (e.g., un puede tambien manipular q) permitiendo al colaborador un

estar potencialmente muy cercano al colaborador u3, y lejos de los colaboradores u1 y u2 en elespacio compartido.

Proximidad logicaObjeto actual o del com-ponente c de un

Objeto potencial q delcomponente d de un

Objeto actual o del compo-nente c de u1

Muy cercano Potencialmente remoto

Objeto actual p del compo-nente c, p 6= o, de u2

Mas o menos cerca Potencialmente remoto

Objeto actual q del compo-nente d, d 6= c, de u2

RemotoPotencialmente mas cer-cano

Tabla 5.3: Proximidad logica entre dos colaboradores dentro del espacio compartido

Las clase involucradas corresponden a: AbstractObject, Activity, Action y SharedObject.La clase SharedObject contiene los objetos compartidos, a los cuales se les puede hacer uncalculo de proximidad logica. La clase AbstractObject permite tener la estructura de arbolpara los documentos de texto y de imagenes, ası como hacer el calculo de dicha proximidad.En el caso de los objetos abstractos referentes tanto al audio como al video, ambos serantratados como un solo objeto compartido dependiendo de las necesidades del proyecto. La claseActivity proporcionara los objetos potenciales; mientras que la clase Action proporcionara elobjeto actual.

5.2.7 Mecanismo tipo de trabajo

El mecanismo tipo de trabajo (DeteccionTipoDeTrabajo) se encarga de determinar comoesta trabajando un grupo de colaboradores, i,e., co-localizadamente, distribuidamente ohıbridamente.

Los parametros necesarios en este mecanismo son los siguientes:

1. el grado de la proximidad logica (cf. Mecanismo proximidad logica 5.2.6);

Capıtulo 5 149

2. el tiempo (hora y fecha) permite registrar el momento en que entra y sale cada colaboradorde un lugar especıfico;

3. la ubicacion de cada colaborador puede ser obtenida por hardware (e.g., sensores infra-rrojos, sensores de Identificacion por Radio-Frecuencia (RFID)) o software (e.g., deteccionde rostros o Near Field Communication (NFC)). La ubicacion puede ser obtenida cuandoel mecanismo DeteccionTipoDeTrabajo lo requiera o puede ser obtenida desde una basede datos. Esto depende de la forma en que se detecta al usuario, e.g., los sensores ubicadosen la entrada de cada habitacion registran la presencia de cada colaborador al momentoque entra a la habitacion, dicho registro se hace sobre una base de datos.

En la figura 5.7 se muestra dos colaboradores (A y B), los cuales tienen asociada una ubicacionfısica (mediante la instancia de la ubicacionFısica). La ubicacion fısica permitira conocerel lugar de trabajo, mientras que el mecanismo de proximidad logica identifica si existe algunarelacion entre los objetos compartidos actuales. Tanto la ubicacion fısica como la proximidadlogica permitiran identificar si los colaboradores trabajan de manera co-localizada, distribuida ohıbrida. Una vez que se determina el tipo de trabajo se pueden hacer adaptaciones contextuales,e.g., desplegar en ciertos dispositivos el espacio publico y en otros el espacio privado o proveerlos ıconos relacionados entorno al rol de los colaboradores.


EntornoComún

Ubicación:ubicaciónFísica

Ubicación:ubicaciónFísica

Ubicación Ubicación

Grado deproximidad

lógica

Mecanismo:DetecciónTipoTrabajo

Mecanismo:ProximidadLógica

tiene

Colaborador:colaborador_A

Actividad:actividad_A

Colaborador:colaborador_B

Actividad:actividad_B

tiene

tiene tiene

actividades actividades

Figura 5.7: Mecanismo de tipos de trabajo


5.3 Marco XARE

El marco XARE (conteXt-Aware groupwaRE) pretende orientar a los disenadores en la creacionde aplicaciones colaborativas adaptativas al contexto de uso, considerando la remodelacion yla redistribucion.

5.3.1 Capas del marco

El marco propuesto se compone de tres capas: deteccion, adaptacion y espacio de trabajo. Lacapa deteccion, que se encuentra en la parte inferior del marco, es responsable de reconocercambios en las variables contextuales, por medio de perceptores logicos y fısicos.

La capa adaptacion analiza la informacion obtenida por la capa deteccion para determinar silos nuevos cambios en el contexto de uso requieren o no la adaptacion de los espacios de trabajopublicos o privados de una aplicacion colaborativa. Cuando la capa adaptacion considere laadaptacion al cambio contextual, esta capa informa a la capa espacio de trabajo como debe serimplementada la adaptacion (cf. Figura 5.8).

La capa superior, espacio de trabajo, es responsable de llevar a cabo la serie de preguntashechas por la capa adaptacion.

La capa deteccion se encarga de detectar de manera automatica algun cambio ocurrido enel contexto, i.e., las cosas relevantes externas al sistema y los eventos ocurridos en la sistema.Esta capa se compone de dos tipos de perceptores

1. Perceptores logicos: son mecanismos de software que pueden identificar cambios en lassiguientes variables contextuales logicas:

• Variable dispositivos: representa las plataformas actuales de interaccion de cada co-laborador; dichas plataformas ejecutan las aplicaciones colaborativas. Mediante estavariable es posible obtener las caracterısticas de hardware y software de los disposi-tivos para adaptar las aplicaciones colaborativas al elemento conjunto de plataformasdel contexto de uso.

• Variable disponibilidad: denota la disponibilidad de cada colaborador, el cual puedeser definida manualmente por el colaborador o de manera automatica, al ser inferidapor la aplicacion colaborativa (cf. seccion 5.2.2). Como se menciono en la seccion5.1, esta variable puede tomar el valor presente o ausente; pero si el colaborador estapresente, el puede estar ocupado, accesible, alcanzable si es posible y disponible.

• Variable actividad actual: representa la actividad en curso de cada colaborador, lacual puede ser inferida automaticamente por una aplicacion colaborativa con baseen las acciones ejecutadas por el colaborador sobre los objetos compartidos.

• Variable proximidad logica: denota la cercanıa entre un colaborador y sus colegasdentro del espacio de trabajo (cf. seccion 5.2.6).

Capıtulo 5 151

Capa de Adaptación

Capa de Detección

Capa de Espacio de Trabajo

Meta- Interfaz de usuario

Sinnegociación

Connegociación

ET privado

ET compartidoMeta-IUplástica

Medios de adaptación

Perceptores lógicos Perceptores físicos

Redistribución

Granularidad del estadode recuperación

Remodelación

Reglas deadaptación

Granularidad deadaptación

modifica

define

definedefine

modifica

Dispositivos Disponibilidad

Actividadactual

Proximidadlógica

Ubicación delcolaborador

Proximidadfísica

Interfacesde usuario

Informacióncontextual

Figura 5.8: Capas del marco XARE

2. Perceptores fısicos: se refieren a sensores que son capaces de reconocer cambios en lasiguientes variables contextuales fısicas:

• Variable configuracion colaborativa de un grupo trabajando: Estos incluyen sensores,tales como RFID (Radio Frequency IDentification) o por la tecnologıa de Bluetooth,que permiten descubrir la entrada o salida de cada colaborador en un lugar especıfico,para determinar si un grupo esta trabajando de manera co-localizada o distribuida.

• Variable proximidad fısica: Este denota la cercanıa entre el dispositivo de un colabo-rador y de su colega. Por medio de esta variable es posible que dos colaboradoresacoplen sus tabletas para crear un espacio publico a partir de dos espacios priva-dos, como en Connectables [Tandler et al., 2001], o extender un espacio de trabajocompartido.

La capa adaptacion esta compuesta de los siguientes modulos:


1. Reglas de adaptacion: con base en la deteccion de cambios en el contexto de uso, estemodulo analiza si la aplicacion colaborativa en cuestion necesita ser adaptada o no. Encaso de que la adaptacion es requerida, este modulo tambien especifica el tipo de tecnicanecesarias para adaptar la aplicacion colaborativa, ası como la granularidad de adaptaciony recuperacion.

2. Medios de adaptacion: se refiere al resultado del proceso de adaptacion percibido por loscolaboradores en la Interfaz de Usuario (IU). Ası, el proceso de adaptacion puede usarvarias de las siguientes tecnicas:

• Redistribucion: consiste en la reorganizacion de los componentes de la IU a diversosdispositivos de interaccion. Cuatro tipos de redistribucion han sido identificados[Calvary et al., 2006]: a) de centralizada a centralizada, cuyo objetivo es conservarel estado centralizado de una IU, e.g., migracion total de una PC a una PDA; b)de centralizada a distribuida, la cual desmiembra una IU en varias plataformas, e.g.,reparticion entre una PC y un PDA; c) de distribuida a centralizada: reconcentrauna IU en una sola plataforma; y d) de distribuida a distribuida, la cual cambia elestado de la distribucion.

• Remodelacion: involucra la reconfiguracion de la IU por medio de insercion,supresion, substitucion y reorganizacion de todos o algunos componentes de la IU.Las transformaciones se aplica a diferentes niveles de abstraccion: intra-modal, inter-modal y multi-modal. La remodelacion intra-modal ocurre cuando los componentesfuentes son redefinidos en la misma modalidad, e.g., si la IU fuente es multi-modal,entonces la IU objetivo tambien sera multimodal, i.e., la remodelacion intra-modal noprovoca ninguna perdida en las modalidades establecidas. En este caso, la modal-idad se preserva, e.g., de grafico a grafico. La remodelacion inter-modal redefineuna modalidad diferente, ya que los componentes fuentes de la IU que necesitanser remodelados se ven afectados al perder o aumentar una modalidad. Ası, una IUmulti-modal puede ser convertida en una IU mono-modal o de manera inversa. La re-modelacion multi-modal permite la combinacion de transformaciones (intra- e ınter-modal), e.g., la herramienta TERESA [Paterno et. al., 2008] utiliza la modalidadgrafica y vocal.

3. Granularidad de adaptacion: denota la unidad mas pequena de la IU que puedeser remodelada y/o redistribuida. Tres granos de adaptacion son identificados[Vanderdonckt, et al., 2008]: a) total, el cual implica modificar completamente la IU;b) espacio de trabajo, el cual se refiere a un espacio logico que apoya la ejecucion de unconjunto de tareas logicamente conectadas, e.g., una ventana de impresion; c) interactor,el cual representa la unidad mas pequena que soporta una tarea, e.g., el boton “Save”de un editor. Otro grano, llamado Pixel, se refiere a cualquier componente de la IU quepuede ser dividido en multiples superficies; sin embargo, este grano de adaptacion soloconcierne a la tecnica de redistribucion.

4. Granularidad del estado de recuperacion: representa el esfuerzo de los usuarios que deben

Capıtulo 5 153

realizar para continuar su actividad despues de ocurrida la adaptacion de la IU. Tresgranos de recuperacion son considerados [Vanderdonckt, et al., 2008]: nivel sesion, elcual fuerza a los usuario a reiniciar, perdiendo el efecto de todas sus acciones ejecutadas;nivel tarea, el cual asegura que todas las tareas terminadas son persistentes, excepto latarea actual interrumpida; nivel de accion fısica, la cual asume que el usuario no pierdeel efecto de ninguna accion.

La capa espacio de trabajo esta compuesto de los siguientes modulos (cf. Figura 5.8):

1. Meta-interfaz de usuario (meta-IU): consiste en un conjunto de funciones, cuyo objetivoes evaluar y controlar de una aplicacion colaborativo. Coutaz y Calvary identifican trestipos de meta-interfaz de usuario [Coutaz and Calvary, 2008]: a) meta-IU sin negociacion,la cual permite observar el estado del proceso de adaptacion, pero no permite que elusuario intervenga; meta-IU con negociacion, la cual es recomendable cuando la meta-IUno puede tomar decisiones entre las multiples formas de adaptacion, o cuando el usuariodebe controlar el resultado del proceso; y c) meta-IU plastica, la cual esta disenada parainstanciar una meta-IU cuando la aplicacion es lanzada en ejecucion.

2. Espacio de trabajo privado: representa el espacio personal donde un colaborador producesus propias contribuciones, las cuales no son visibles a sus colegas.

3. Espacio de trabajo compartido: simboliza el espacio comun donde los miembros de ungrupo coopera al hacer sus contribuciones perceptibles a todos los miembros del grupocolaborativo, cuando la estratificacion no existe o, de otra manera, por algunos miembros.

El almacenamiento que usa el marco XARE esta compuesto de dos repositorios (cf. Figura5.8):

1. El repositorio de informacion contextual principalmente administra y almacena infor-macion estable, e.g., preferencias de los colaboradores, perfiles, ası como tareas y activi-dades potenciales. Cuando el dispositivo de un colaborador no tiene suficientes capaci-dades para almacenar informacion dinamica (e.g., la ubicacion actual del colaborador, losobjetos compartidos en uso y las caracterısticas de los dispositivos actuales), esta base dedatos esta encargada de almacenar dicha informacion.

2. Para dispositivos con poca capacidad de almacenamiento, el repositorio de interfaces deusuario almacena y administra informacion necesario para desplegar las interfaces deusuario (e.g., diferentes vistas de interaccion y espacios de trabajo, frecuencia de uso dealgunos interactores) y el estado de recuperacion (e.g., todas las acciones ejecutadas otareas terminadas).


5.4 Conclusiones

El marco propuesto puede servir como referencia para crear aplicaciones colaborativas plasticas,ya que es posible observar las dependencias que existen entre las clases y los elementos delcontexto de uso. Dicho marco considera la mayorıa de los escenarios propuestos en el capıtulo4, en especifico aborda los escenarios implementados.

En la tabla 5.4 se proveen mecanismos para implementar cuatro de los ocho escenarios pre-sentados. El escenario “mejoramiento del trabajo colaborativo”, el cual se refiere a crear ligasentre una palabra clave de la mensajerıa instantanea y un objeto compartido de un editor co-laborativo mediante la funcion de deixis, puede ser implementado mediante el mecanismo de“creacion de hiperligas entre los objetos compartidos”. Este mecanismo permite crear ligas nosolo desde una aplicacion de mensajerıa instantanea sino desde cualquier otra aplicacion. Estose puede lograr gracias a que la clase Link es parte del Desktop.

Escenario Mecanismos

1. Mejoramiento del trabajo co-laborativo

5.2.5. Creacion de hiperligas entre ob-jetos compartidos

2. Remodelacion de componentesde la interfaz de usuario

5.2.4. Ocultar, sustituir o mostrarcomponentes

3. Redistribucion del sistema co-laborativo en funcion de la config-uracion del grupo

5.2.7. Ubicacion fısica y5.2.6. Proximidad logica

4. Adaptar los medios de con-tacto y disponibilidad

5.2.1. Similaridad de actividades,5.2.2. Disponibilidad y5.2.3. Medio de contacto

Tabla 5.4: Sugerencia para llevar a cabo cuatro escenarios

En el caso del escenario “remodelacion de componentes de la interfaz de usuario” que per-mite la modificacion de componentes mediante ocultacion, agregacion o sustitucion puede serimplementado siguiendo los mecanismo de “ocultar, sustituir y mostrar componentes”. Dichomecanismo permite adaptar los componentes dependiendo de los roles y del conjunto de dis-positivos en uso de los colaboradores. Este mecanismo puede usarse para ocultar los ıconos norelacionados con los roles, cuando la pantalla del dispositivo en uso tenga una baja resoluciono sea de tamano muy pequeno. Ademas, las aplicaciones pueden optar por calcular la remod-elacion de la IU en caso de que el dispositivo soporte dicho calculo o por usar un servidor paraque este les proporcione la IU, considerando las caracterısticas del contexto actual (dispositivo

Capıtulo 5 155

y colaboradores).

El escenario “redistribucion del sistema colaborativo en funcion de la configuracion delgrupo” permite adaptar componentes dado el tipo de interacciones (co-localizadas, distribuidaso hıbridas) puede llevarse acabo utilizando los dos mecanismos siguientes: 1) “proximidadlogica” permite identificar si el grupo de colaboradores se encuentra trabajando en la mismatarea; y, 2) “tipo de trabajo” permite detectar cuando un grupo esta trabajando en un mismolugar fısico o a distancia.

El escenario “adaptar los medios de contacto y disponibilidad” permite adaptar los mediosde contacto y disponibilidad de los colaboradores puede llevarse acabo al usar los siguientestres mecanismos: 1) “similaridad de actividades” permite determinar la similaridad de lasactividades de dos colaboradores, 2) “disponibilidad de un colaborador” permite calcular ladisponibilidad del colaboradores al usar la similaridad de las actividades del usuario a contactary el que desea hacer el contacto, y 3) “medios de contacto” permite definir los medios de contactoconsiderando la disponibilidad y el hardware de los colaboradores mencionados.

Existen dos escenarios que no se muestran en la tabla, pero pueden ser parcialmente im-plementados usando los mecanismos existentes. Estos escenarios corresponden a: “adaptar lainformacion” (cf. seccion 4.8) y “uso de diferentes modalidades en la notificacion” (cf. seccion4.9).

El escenario “adaptar la informacion”, que tiene como objetivo proveer informacion dado uncontexto determinado, puede implementarse casi por completo al usar los siguientes mecan-ismos: 1) “ocultar, sustituir y mostrar componentes” puede usarse para proveer informacionnecesaria dado el rol del colaborador y el dispositivo en uso, 2) “proximidad logica” nos per-mitira saber el momento en que entra un colaborador a un lugar especıfico y ası proveer lainformacion adecuada dado su rol y actividades y 3) “similaridad de actividades” permite de-tectar la similaridad de actividades entre dos colaboradores, dicho mecanismo permitira ofrecerinformacion entre colaboradores dada sus actividades actuales o potenciales.

El escenario “uso de diferentes modalidades en la notificacion” tiene como objetivo notificarusando diferentes modalidades. Este escenario se puede implementar parcialmente al usarlos siguientes dos mecanismos: 1) “proximidad logica” para conocer en donde se encuentrael colaborador y ası determinar si esta solo o acompanado, y 2) “similaridad de actividades”para determinar si la actividad del colaborador que genera la actividad esta relacionada con laactividad del que potencialmente recibira dicha notificacion.


Capıtulo 6

Validacion del marco Xare

6.1 API del marco Xare

El marco para la adaptacion al contexto de uso se compone de tres capas: espacio de trabajo,adaptacion y deteccion (cf. Figura 6). Los componentes con letras grises, e.g., espacio detrabajo privado y compartido, de la figura 6 corresponden a los componentes que no se utilizanen este escenario.

La capa deteccion se encarga de detectar tanto el contexto interno (e.g., objeto compartidoen uso) como el contexto externo del sistema (e.g., los colaboradores se encuentran trabajandoen la sala de juntas).

La capa de adaptacion, ubicada entre las capas deteccion y espacio de trabajo, recibe lainformacion de las dos capas contiguas para analizar si los nuevos cambios contextuales orig-inan alguna de las siguientes adaptaciones: remodelacion, redistribucion y contexto de uso(colaborador, conjunto de plataformas y entorno comun).

La capa espacio de trabajo permite interactuar con el usuario final, ademas de mostrar lasadaptaciones usando alguna modalidad.

El componente intermediario en cualquiera de las capas permite pasar informacion de unacapa a otra, ya que dichos componentes direccionan las solicitudes recibidas y las respuestasgeneradas. De esta manera al agregar un nuevo componente en cualquiera de la capas solo sele debe informar al respectivo componente intermediario sin necesidad de modificar el resto delos componentes.

La funcionalidad del resto de los componentes es detallada cuando se describe el fun-cionamiento del escenario propuesto dentro del marco.

Cuando un dispositivo tiene suficientes capacidades para almacenar y procesar las IU ade-cuadas, la aplicacion en ejecucion es capaz de adaptarse por si misma de manera autonoma.

157

158 Validacion del marco Xare

Sin embargo, sin considerar las computadoras portatiles, la mayorıa de los dispositivos podrıannecesitar una entidad externa (e.g., servidores) para desplegar una IU adecuada. La entidadexterna considera las caracterısticas de hardware y software del dispositivo huesped, para iden-tificar la IU. Esta tarea es lograda por dos tecnicas las cuales son:

1. los dispositivos moviles toman la iniciativa de informar a la entidad externa acerca desus propias capacidades. Esta solucion es adecuada para soluciones basadas en la Web,donde los dispositivos moviles actuan como clientes y la entidad externa como servidor;

2. la entidad externa pregunta a los dispositivos moviles acerca de sus capacidades. Estaopcion es adecuada cuando los dispositivos moviles tienen capacidades para responderpeticiones.

6.2 Medio de contacto y disponibilidad”

6.2.1 Dimensiones abordadas en esta propuesta

En el escenario se abordan dos adaptaciones al contexto, los cuales son: disponibilidad ymedios de contacto. Ambas adaptaciones son analizadas considerando las diez dimensiones quela mayorıa pertenecen a los problemas encontrados en la interfaz plastica [Vanderdonckt, et al.,2008]. En la tabla 5 se resume las dimensiones abordadas en este escenario.

Lo que sigue corresponde a dos escenarios: disposnibilidad y objetos referenciados. Verificarsi corresponde al descrito arriba Las dimensiones que estan involucradas en la adaptacion delmedio de contacto y la disponibilidad al contexto corresponden al grupo de colaboradores(GrupoDeColaboradores) y al conjunto de plataformas (ConjuntoDePlataformas). Las clasesinvolucradas en esta propuesta corresponden a las clases: Hardware, Software, Actividad,MedioDeContacto y Disponibilidad, las cuales se encuentran en marcadas con lınea gruesade color negro (cf. Figura 5).

La clase Actividad tiene varios metodos y atributos, solo que por cuestiones de espaciose especifican los mas representativos. Ademas, la clase Actividad se asocia consigo mismapara determinar la similitud entre las actividades de dos colaboradores. La similitud entreactividades se realiza mediante el metodo similitud que tiene como parametros de entradatodas las actividades de los dos colaboradores (Ac1 y Ac2), incluyendo la actividad actual deambos colaboradores. El metodo similitud implementa las reglas mostradas en la tabla 1.

falta diagrama

La clase Disponibilidad depende de la clase Actividad para usar el metodo similitud, el cualregresa la similitud entre el colaborador observado y el observador. El metodo disponibilidad re-quiere la similitud entre las actividades ademas de conocer la fecha lımite de la actividad actual,

Capıtulo 6 159

del colaborador observado, para aplicar las reglas mostradas por el mecanismo de Disponibilidad(cf. Tabla 2).

Otra de las clases importantes en esta propuesta es el MedioDeContacto que depende devarias clases, las cuales son: Hardware, Software, Actividad y Disponibilidad. Mediante lasdependencias, la clase MedioDeContacto obtiene una serie de parametros, e.g., el hardware queesta utilizando cada colaborador y el software disponible para llevar a cabo algun medio decomunicacion.

La clase Hardware debe determinar los dispositivos en uso de los colaboradores a traves delmetodo hardDisponible. Dicho metodo requiere como parametro el nombre del colaborador (oun identificador de identidad) en cuestion. El metodo hardMediosContacto busca los compo-nentes del dispositivo necesarios para llevar a cabo los medios de contacto, e.g., este metodoverificar la existencia de una camara web, altavoces y microfono para la video-conferencia. Enel caso de la clase Software, esta se encarga de buscar que aplicaciones permiten la comuni-cacion entre los colaboradores por medio del metodo softMediosContacto, cuyo parametro deentrada es el dispositivo a analizar.

El medio de contacto es calculado dada la similitud entre las actividades o la disponibilidaddel colaborador observado. Cuando se calcula el medio de contacto considerando la simili-tud entre las actividades, el metodo medioActividad realiza el calculo usando la tabla 3 cuyosparametros corresponden a: 1) similitud entre actividades, 2) hardware disponible y 3) softwaredisponible. En el caso de calcular los medios de contacto tomando como parametro principalla disponibilidad, del colaborador observado; el metodo encargado del calculo es medioDisponi-bilidad. Este metodo requiere de las reglas mostradas en la tabla 4, ası como tres variables:1) disponibilidad del colaborador observado, 2) hardware disponible y 3) software disponible.Tanto el metodo medioActividad y medioDisponibilidad pueden requerir usar las preferenciasde los medios de contacto establecidos por el colaborador, los cuales se obtienen de la clasepadre Preferencia.

El contexto de uso de los sistemas cooperativos se refiere a la tercia: grupo de colaboradores,conjunto de plataformas y entorno comun. Tanto la disponibilidad como el medio de contextose adaptan al grupo de colaboradores; en cambio, el medio de contexto es el unico que se adaptaal conjunto de plataformas y al entorno comun. La adaptacion al grupo de colaboradores porparte de la disponibilidad se hace al consideras las actividades de los colaboradores involucrados(observado y observador). La adaptacion al grupo de colaboradores por parte de los mediode contacto se lleva a cabo al considerar la disponibilidad y las preferencias del colaboradorobservado, y la similitud de actividades entre el colaborador observado y el observador. Laadaptacion a la plataforma se realiza al solicitar tanto el hardware como el software actualde los colaboradores para comunicarse mediante los medios de contacto, e.g., para una video-conferencia se requiere de hardware (e.g., camara web, altavoces y microfono) y se softwareque permita el dialogo (e.g., Google talk y Skype). La adaptacion al entorno ocurre cuandoel telefono de Sandy busca un dispositivo de computo que pueda ser usado para llevar a cabola video-conferencia, los lugares en donde se busca este dispositivo es por donde Sandy va


caminando.

Dimension Adaptacion Dimension AdaptacionContexto de Uso V Despliegue de la IU X

Percutor de plastici-dad

V Espacio tecnologico X

Grano de adaptacion V Tipo de adaptacion V

Grano de recu-peracion

X Variables contextuales V

Meta-IU V Tipo de entidad V

El percutor de plasticidad [Vanderdonckt, et al., 2008] considera la adaptacion por re-modelacion, re-distribucion y migracion. Este escenario considera la adaptacion por re-modelacion al ocultar al colaborador los iconos de los medios de contacto no permitidos.En consecuencia la interfaz de usuario cambia para mostrar solo aquellos medios de contactodisponibles para el colaborador.

El grano de adaptacion [Vanderdonckt, et al., 2008] senala el grado en que la interfaz deusuario ha sido metamorfoseada despues de la adaptacion. El grano de adaptacion se clasificaen: a) pixel, b) interactor, c) espacio de trabajo e d) interfaz de usuario completa. La interfaz deusuario del escenario se remodela a nivel interactor al momento de que el colaborador observadorda clic sobre la foto de un colega, en ese momento aparece un menu desplegable que actualiza ladisponibilidad. El medio de contacto tambien sigue una remodelacion a nivel interactor porquelos iconos no accesibles, tanto en el menu desplegable como en la ventana medios de contacto,estan ocultos.

El grano de recuperacion del estado [Vanderdonckt, et al., 2008] caracteriza el esfuerzo delos usuarios que deben realizar para continuar su actividad despues de ocurrida la adaptacion.Tres tipos de granos de reanudacion son posibles: a) accion fısica, b) tarea y c) sesion. Enel escenario no se considera la recuperacion del estado porque posiblemente no se pierda lainformacion al mostrar la disponibilidad ni el medio de contacto del colaborador.

El concepto de Meta-Interfaz de Usuario (Meta-IU) [Vanderdonckt, et al., 2008] se definecomo la simplificacion de un entorno de desarrollo de usuario final. La meta-IU consideracuatro niveles: 1) plasticidad en la propia meta-IU, 2) meta-IU sin negociacion, 3) meta-IUcon negociacion y 4) inexistente. En el escenario propuesto se implementa una meta-IU connegociacion. Dicha meta-IU se ejecuta cuando el colaborador observador coincide con el colabo-rador observado en mas de una aplicacion para llevar a cabo la comunicacion, e.g., aplicacionesde mensajerıa instantanea como Google Talk, Windows Live Messenger y el mensajero nativodel espacio de trabajo. En ese caso se le proporciona al colaborador observador las opcionesdisponibles a traves de una ventana.

Despliegue de la interfaz de usuario [Vanderdonckt, et al., 2008] permite conocer si al realizarla adaptacion plastica se utilizan interfaces de usuario: a) prefabricadas o b) generadas en

Capıtulo 6 161

tiempo de ejecucion. En este escenario no se provee la informacion suficiente para determinar laimplementacion de las interfaces de usuario, pero podrıa generarse IU prefabricadas o generadasen tiempo de ejecucion.

El Espacio Tecnologico (ET) [Vanderdonckt, et al., 2008] es un contexto de trabajo que in-corpora un conjunto de conceptos asociados, bases de conocimientos, herramientas, habilidadesrequeridas y posibilidades. Los espacios tecnologicos se dividen de la siguiente manera: intra-ET, interET y multi-ET. En este escenario no se considero el espacio tecnologico, pero podrıaaplicarse multi-ET al proveer la disponibilidad y los medios de contacto en algunos dispositivosde manera grafica y en otros, audio.

Tipo de adaptacion [Abowd et al., 1999] comprende las siguientes tres maneras: 1) pre-sentacion de informacion y servicios al usuario, 2) ejecucion automatica de un servicio e 3)informacion aumentada. La disponibilidad como en el medio de contacto se enfoca a la pre-sentacion de informacion y servicios al usuario. El mecanismo de la disponibilidad muestra elestado de disponibilidad del colaborador dependiendo de las variables contextuales del obser-vador como del observado. Por otro lado, el mecanismo que calcula los medios de contacto solomuestra las opciones disponibles que tiene el colaborador observador. Aun cuando la disponibil-idad y el medio de contacto hacen operaciones para determinar las funcionalidades necesarias,al final de dichas operaciones solo muestra la informacion.

Las variables contextuales se refiere a las variables relevantes que los sistemas consideran parallevar a cabo la adaptacion [Ghiani et al., 2009]. Las variables contextuales para la disponibil-idad corresponde a: similitud entre actividades del colaborador observado y el observador, yla fecha lımite de la actividad actual del colaborador observado. En el caso de los medios decontacto, las variables contextuales se refieren a: similitud entre actividades del colaboradorobservado y el observador, la disponibilidad del colaborador observado y la preferencia respectoa los medios de contacto del colaborador observado.

Tipo de entidad [Olivares, 2011] se refiere a considerar una sola entidad (e.g., un usuario oun dispositivo) o varias entidades a lo largo de la ejecucion del sistema. El escenario consideramultiples entidades ya que toma en cuenta variable de dos colaboradores de forma simultaneapara calcular tanto la disponibilidad como el medio de contacto.

6.2.2 Relacion entre la propuesta y el marco de adaptabilidad

plastica

Esta seccion se encuentra dividida en dos partes: la primera especifica la funcionalidad de cadacapa y la segunda describe el proceso necesario para llevar a cabo el escenario propuesto. Enla segunda parte se resalta el flujo de informacion entre cada capa, ası como la relacion entrela capa y los mecanismos de los diagramas de bloques.


Descripcion del escenario dentro del marco

La adaptacion al contexto a traves del medio de contacto y la disponibilidad empieza desdela capa superior, espacio de trabajo, ya que el usuario ingresa al espacio de trabajo. Una vezque el espacio de trabajo identifica al colaborador conectado envıa dicha informacion a la capade adaptacion y deteccion. Las reglas de la capa de adaptacion determinan que la identidaddel colaborador tiene que ser tratada en el componente contexto de uso, perteneciente a lacapa de adaptacion. La capa de adaptacion envıa la identificacion del colaborador hacia lacapa deteccion para que se actualice el registro del colaborador, i.e., en la base de datos decolaboradores se registra la hora y fecha de ingreso del colaborador al espacio de trabajo.

Por su parte el componente colaborador solicita informacion (e.g., roles y actividades aso-ciadas al colaborador) a la capa deteccion para adaptar el espacio de trabajo al colaboradorque recien ingreso (e.g., mostrar las aplicaciones necesarias para llevar a cabo sus actividades).Figura 6. Marco de adaptabilidad plastica para sistemas colaborativos

Adaptacion de la disponibilidad al contexto

El colaborador, despues de identificarse, puede establecer su medio de contacto y su disponibili-dad, manual o automatica, en la capa espacio de trabajo mediante una ventana de configuraciondel medio de contacto y disponibilidad. La primera opcion a configurar es la disponibilidadpuesto que puede ser requerida para establecer los medios de contacto. Cuando se establece ladisponibilidad de manera manual, el usuario selecciona simplemente el estado de disponibilidad,e.g., alcanzable si es posible.

En el caso de que un colaborador permita que su disponibilidad sea establecida de maneraautomatica, como se observa en el siguiente parrafo proveniente del escenario: Isaac ingresa alespacio de trabajo ... El espacio de trabajo compartido define la disponibilidad de Isaac como:1) “ocupado” para todas la personas que estan fuera de la preparacion del documento tecnico;2) “alcanzable si es posible” para los colegas cuya actividad actual no es similar a la de Isaacpero su actividad potencial lo es (en terminos de los objetos compartidos), y 3) “accesible”para los colegas cuya actividad actual es similar a la de Isaac.

Describiendo el proceso anterior, el espacio de trabajo envıa hacia la capa adaptacion lainstruccion de calcular automaticamente la disponibilidad del colaborador. El intermediario dela capa de adaptacion recibe dicha instruccion, posteriormente este componente envıa dicha in-struccion al componente colaborador. Cuando el componente colaborador recibe la instruccionde calcular automaticamente la disponibilidad establece las reglas a seguir, en el escenario prop-uesto se da una sugerencia de dichas reglas que se resumen en la tabla 2. En la tabla 2 se sugiereestablecer la disponibilidad dependiente de la similitud entre las actividades del colaboradorobservado y el observador, ası como de la fecha lımite de la actividad actual del colaborador.

Retomando parte de un parrafo del escenario que ejemplifica cuando un colaborador necesitaconocer la disponibilidad de otro, es el siguiente: Por un momento, Sandy escribe la seccion de

Capıtulo 6 163

introduccion, posteriormente interrumpe esta actividad para contactar a Isaac. Ella coloca sucursor sobre la foto de Isaac (en el widget de conciencia de colaboradores) y como resultado,un menu desplegable aparece para mostrar: la disponibilidad de Isaac y el medio de contactopara comunicarse con el.

Cuando Sandy coloca su cursor sobre la foto de Isaac, la capa espacio de trabajo solicita a lacapa adaptacion dos datos: 1) la disponibilidad de Isaac y 2) los medios de contacto. En la capaadaptacion, el intermediario al recibir dicha solicitud la transfiere al componente colaborador.La capa colaborador solicita a la capa deteccion las actividades actuales y potenciales, ası comola fecha lımite de la actividad actual de Isaac (colaborador observado). Cuando el componentecolaborador obtiene la informacion solicitada, este componente primero calcula la similitudentre actividades para despues calcular la disponibilidad de Isaac. Al terminar los computos, elcomponente colaboradores regresa la disponibilidad de Isaac al componente intermediario, a suvez este componente le regresa la disponibilidad a la capa espacio de trabajo. La capa espaciode trabajo le informa a la aplicacion, que solicito la disponibilidad de Isaac, la respuesta.

Adaptacion de los medios de contacto al contexto Los medios de contacto pueden ser estable-cidos manualmente o automaticamente dentro de la ventana “Medios de contacto”, la cual estacontenida en la capa espacio de trabajo. Un ejemplo de establecer manualmente los medios decontacto se muestra en el siguiente parrafo, el cual pertenece al escenario mostrado al iniciode esta propuesta: Sin embargo, Isaac decide establecer su medio de contacto como sigue: 1)cuando el este “ocupado”, el puede ser solamente contactado por correo electronico, ası quetemas. . . ; 2) cuando el este “alcanzable si es posible”, el puede ser solo contactado por men-sajerıa instantanea, ası. . . , y finalmente 3) cuando el este “accesible”, el puede ser contactadopor video-conferencia, audio o mensajerıa instantanea porque. . .

Cuando el colaborador selecciona la opcion manual, el espacio de trabajo solo debe desple-gar los medios de contacto soportados por los dispositivos que actualmente esta usando elcolaborador. A consecuencia, el espacio de trabajo solicita a la capa adaptacion los mediosde contacto soportados por los dispositivos. La solicitud recibida por la capa adaptacion estransferida al componente intermediario de dicha capa, para que este dirija la solicitud al com-ponente plataforma. Este ultimo componente solicita a la capa deteccion los dispositivos enuso del colaborador, dicha solicitud es a traves del componente intermediario. El componenteintermediario, de la capa deteccion, envıa la solicitud al componente hardware para que esteindique cuales son los dispositivos en uso.

Despues de que el componente plataforma recibe los dispositivos en uso, e.g., computadoraportatil, ejecuta la clase Hardware, de la figura 5, para verificar la existencia de los dispositivosauxiliares y aplicaciones necesarias para llevar a cabo la comunicacion, e.g., para la video-conferencia se necesitan detectar los siguientes dispositivos auxiliares: camara web, altavoces ymicrofono, y las aplicaciones necesarias para una vide-conferencia pueden ser: Skype, Oovoo,Google talk, etc. Dicha solicitud llega al intermediario, de la capa deteccion, este componentesolicita a los componentes hardware y software determinar la existencia de camara web yaltavoces ası como las aplicaciones necesarias para llevar a cabo la comunicacion. La deteccion


de dichos dispositivos y aplicaciones puede realizarse mediante programas o recurrir a las basesde datos para extraer dicha informacion.

Despues de obtener la informacion solicitada, los componentes hardware y software regresanla informacion al intermediario, de la capa deteccion, para que sea enviada a la capa adaptacion.Esta capa al recibir la informacion la analiza mediante reglas para determinar los medios de con-tacto disponible, dado las caracterısticas de hardware y software del equipo en uso. Finalmente,dicha informacion es enviada a la capa espacio de trabajo.

En la capa espacio de trabajo se informa a la aplicacion que solicito los medios de contactodisponibles, en este caso a la ventana medios de contacto, para que las opciones disponiblessea mostrada al colaborador. Posteriormente, el colaborador tiene que determinar su medio decontacto considerando su disponibilidad o la actividad, ası como el medio de contacto requerido.

En el proceso anterior se describio la manera en que interviene el marco propuesto cuando unusuario determina manualmente sus medios de contacto. La siguiente explicacion es referentecuando el colaborador decide que el medio de contacto sea establecido por el espacio de trabajo.El espacio de trabajo calcula el medio de contacto basandose en la actividad, pero podrıa basarsedicho calculo en la disponibilidad. En el escenario se proporciona los medios de contactobasandose en la similitud de las actividades. El siguiente parrafo fue tomado del escenario:El espacio de trabajo compartido tambien determina que Sandy puede ser contactada por: 1)anotaciones privadas en el texto o mensajerıa instantanea por colegas cuyas actividades (actualo potencial) son muy similares a las suyas y 2) los medios de comunicacion de la preferencia deSandy en cualquier otro caso.

El calculo automatico del medio de contacto frecuentemente lo hace el espacio de trabajo en elmomento que un colaborador solicita comunicarse con un colega. La solicitud se hace cuando elcolaborador coloca su cursor sobre la foto de un colega como se muestra en el siguiente parrafo,el cual fue tomado del escenario: Al momento de que Alice se encuentra realizando la actividadde revisar la seccion de desarrollo, ella requiere contactar a Sandy... Cuando ella coloca sucursor sobre la foto de Sandy, Alice observa que la disponibilidad de Sandy es “Accesible”,dado que ambas estan trabajando en el mismo reporte tecnico. Tambien Alice nota que losmedios de contacto disponible de Sandy corresponden a la mensajerıa instantanea y correoelectronico, ya que ambos medio son de la preferencia de Sandy. Al seleccionar Alice. . .

Cuando Alice coloca su cursor sobre la foto de Sandy aparece la disponibilidad y los mediosde contacto relacionados con Sandy. Internamente, la aplicacion que usa Alice solicita a la capaespacio de trabajo la disponibilidad y los medios de contacto relacionados con Sandy. En estaparte de la seccion se abordada solo los medios de contacto ya que la disponibilidad fue tratadapreviamente.

La capa espacio de trabajo solicita a la capa adaptacion los medios de contacto en comunentre Alice y Sandy, tomando en cuenta la preferencia de Sandy para ser contactada. Elcomponente intermediario de la capa adaptacion solicita al componente colaborador los mediosde contacto disponibles que tiene Alice para contactar a Sandy. A su vez, este componente

Capıtulo 6 165

solicita a la capa deteccion consultar si Sandy establecio los medios de contacto. En el caso derecibir una respuesta negativa, el componente colaborador debe aplicar las reglas de la tabla 3.

La solicitud de verificar si Sandy establecio los medios de contacto recibida por la capadeteccion es transferida al componente intermediario. Este componente accede a la base dedatos colaboradores y accede a la informacion solicitada. Entre los componente intermediariosse comunican para informar que Sandy no establecio manualmente los medios de contacto.Cuando el componente colaborador recibe la respuesta negativa a su solicitud, este componentecalcula la similitud, entre Sandy y Alice, teniendo como resultado que la similitud entre lasactividades potenciales es mas o menos similar. El componente colaborador sigue las reglas dela tabla 3, por tal motivo solicita la preferencia de Sandy ante los medios de contacto a travesde los componentes intermediarios.

Al recibir la solicitud de la preferencia de los medios de contacto de Sandy, el componenteintermediario, de la capa deteccion, accede a la base de datos colaboradores para extraer lapreferencia de ella. Dicho componente le informa a su sımil de la capa adaptacion que lacolaboradora Sandy tiene como medio de contacto preferente la mensajerıa instantanea y elcorreo electronico.

El componente intermediario, de la capa adaptacion, transfiere la informacion recibida alcomponente colaborador. El componente solicita nuevamente a la capa deteccion el hard-ware y software necesario para llevar a cabo la mensajerıa instantanea y el correo electronico.Posteriormente, el componente colaborador informa al componente re-modelacion los iconosdisponibles de los medios de contacto, e.g., Alice tiene solo la opcion de mensajerıa instantaneay correo electronico, ası que el resto de iconos relacionados con el medio de contacto deben serocultados. El componente re-modelacion debe informar a las capas adyacentes cuales son losiconos disponibles para que la colaboradores Alice contacte a Sandy. Ademas, el componentere-modelacion debe hacer los calculos pertinentes para reacomodar los iconos en caso de sernecesario.

En el caso que exista mas de un software para ejecutar el medio de contacto, como ocurreen el complemento del parrafo anterior perteneciente al escenario, se ofrece al colaborador lasopciones posibles, e.g., Al seleccionar Alice la mensajerıa instantanea, el espacio de trabajole ofrece los posibles medios de contacto (e.g., Google Talk, Windows Live Messenger y elmensajero nativo del espacio de trabajo) que tienen en comun ellas. Alice selecciona GoogleTalk. El espacio de trabajo le informa a Sandy que Alice desea contactarlo por medio dela mensajerıa; ademas dicho espacio sugiere usar Google Talk ya que fue la eleccion de ella.Finalmente, Alice acepta la comunicacion usando el mensajero instantaneo propuesto por Alice.

El componente colaborador envıa las opciones disponibles a la capa espacio de trabajo me-diante el componente intermediario. La capa espacio de trabajo reenvıa esa informacion alcomponente meta-IU para que este despliegue al colaborador las opciones actuales. Cuando elcolaborador selecciona una opcion, dicha informacion es regresada a la capa adaptacion. A suvez, la capa adaptacion envıa la seleccion de la aplicacion a la capa deteccion para registrardicha accion.


6.3 Conclusiones

Gracias a la API presentada en este capıtulo, los desarrolladores de sistemas colaborativosplasticos pueden crear sus aplicaciones. Ademas, ellos pueden ayudarse a usar dicha API,gracias al escenario presentado, el cual hace uso de dicha API.

Capıtulo 7

Conclusiones y trabajo a futuro

En la seccion 7.1 se presentan las conclusiones hasta el momento y en la seccion 7.2 se presentael trabajo a desarrollar para terminar este tema de investigacion.

7.1 Conclusiones

Cap2. Este capıtulo muestra una subarea del campo de Interaccion Humano-Computadora(IHM) llamada “Plasticidad de las Interfaces de Usuario”; dicha subarea es importante parael desarrollo del presente trabajo de investigacion porque propone considerar varios puntosrelevantes para crear una interfaz de usuario plastica en la etapa de diseno o en tiempo deejecucion. Tambien, sistemas plasticos deben informar al usuario final acerca de la nuevaadaptacion, ya sea que el usuario intervenga en el proceso de adaptacion o solo sea un observadorpasivo.

Varios de los sistemas de ejemplo permiten expresar de manera visual la plasticidad, e.g.,cambiar de modalidad grafica a textual cuando el dispositivo no lo soporte; redistribuir la IUentre dispositivos heterogeneos (e.g., pizarrones electronicos, PDA, PC y mesas) y adaptarse ala tarea del colaborador.

En los ejemplos presentados, se observa que la mayorıa de los sistemas se adaptan a laplataforma, principalmente estos sistemas se ejecutan sobre PDAs, tablets PC y computadorasportatiles; otras plataformas menos usadas son pizarrones electronicos, telefonos inteligentes orelojes. Muy pocos de estos sistemas consideran al usuario. La tendencia respecto al usuarioes considerar las tareas (frecuencia y preferencia) o reconocer cuando un mismo usuario estausando dos o mas dispositivos.

Cap3. Los marcos descritos en esta seccion fueron seleccionados debido a que implementanalgunas de los caracterısticas de las interfaces de usuario plasticas multimodales.

167

168 Conclusiones y trabajo a futuro

Dado el analisis de los marcos con respecto al contexto de uso se puede observar que existe latendencia en considerar varias peculiaridades del usuario , e.g., el perfil, las tareas asignadas yel rol, con la finalidad de proveer una mejor adaptacion. Las caracterısticas anteriores cada vezconsideran aspectos muy finos, e.g., las acciones realizadas dentro del sistema y las preferenciasrespecto a un tema. Por otro lado, la adaptacion a la plataforma se centra en acoplarse alas caracterısticas que ofrece cada dispositivo de computo, pero la tendencia en este punto esconsiderar sensores para permitir la conciencia del entorno fısico, ademas de crear clusters demanera dinamica con los dispositivos al alcance de los usuarios. En cuanto la adaptacion alentorno, los marcos estan tendiendo a modelar el entorno fısico, e.g., detectar las personas enun lugar, ası como proporcionar informacion relevante a cada usuario.

Retomando los puntos relevantes de las interfaces de usuario plasticas se observa que losmarcos se inclinan por permitir que los usuarios finales intervengan en la adaptacion medianteuna META-IU, ası como llevar la adaptacion en tiempo de ejecucion, dejando de lado los demaspuntos a considerar.

Cap4 El diagrama de clases propuesto puede servir como referencia para crear aplicacionesplasticas cooperativas ya que se pueden observar las dependencias que existen entre las clasesy las dimensiones del contexto de uso. Dicho diagrama considera la mayorıa de los escenariospropuesto en el capıtulo 4, en especifico aborda los escenarios que tienen implementadas susaplicaciones

En la tabla 5.4 se provee mecanismos para implementar cuatro de los ocho escenarios presen-tados. El escenario que considera los objetos compartidos, el cual se refiere a crear ligas entreuna palabra clave de la mensajerıa instantaneas y un objeto compartido del editor colabora-tivo mediante la funcion Deixis, puede ser implementado mediante el mecanismo 5.2.5. Estemecanismo podrıa permitir crear ligas no solo desde la aplicacion de mensajerıa instantaneasino desde cualquier otra aplicacion, esto se puede lograr gracias a que la clase Link es partedel SharedWorkspace.

En el caso del escenario que permite la modificacion de componentes mediante la ocultacion,agregacion o sustitucion puede ser implementado siguiendo los mecanismo 5.2.4. Dicho meca-nismo permite adaptar los componentes dependiendo de los roles del colaborador y del conjuntode dispositivos en uso. Este mecanismo puede usarse para ocultar los ıconos no relacionadoscon el rol, cuando la pantalla del dispositivo en uso tenga una baja resolucion o sea de tamanomuy pequeno. Ademas las aplicaciones pueden optar por calcular la remodelacion de la IU en elcaso de que el dispositivo soporte dicho calculo o usar un servidor para que este les proporcionela IU considerando las caracterısticas del contexto (dispositivo y colaboradores) actual.

El escenario que permite adaptar componentes en las interacciones co-localizadas, dis-tribuidas o hıbridas puede llevarse acabo utilizando los dos mecanismos siguientes: 1) el mecan-ismo 5.2.6 permitira identificar si el grupo de colaboradores se encuentra trabajando en lamisma tarea; mientras que, 2) 5.2.7 que permite detectar cuando un grupo esta trabajando enun mismo lugar fısico o a distancia.

Capıtulo 7 169

El escenario que permite adaptar los medios de contacto y disponibilidad de los colaboradorespuede llevarse acabo al usar los siguientes tres mecanismos: 1) 5.2.1 permite determinar lasimilaridad de las actividades de dos colaboradores, 2) 5.2.2 permite calcular la disponibilidaddel colaboradores al usar la similaridad de las actividades del usuario a contactar y el quedesea hacer el contacto, y 3) 5.2.3 permite definir los medios de contacto considerando ladisponibilidad y el hardware de los colaboradores mencionados.

Existen dos escenarios que no se muestran en la tabla, pero pueden ser parcialmente imple-mentados usando los mecanismos existentes. Estos mecanismos corresponden a: 4.8 y 4.9.

El escenario 4.8, que tiene como objetivo proveer informacion dado un contexto determinado,puede implementarse casi por completo al usar los siguientes mecanismos: 1) 5.2.4 puede usarsepara proveer informacion necesaria dado el rol del colaborador y el dispositivo en uso, 2) 5.2.7nos permitira saber el momento en que entra un colaborador a un lugar especıfico y ası proveerla informacion adecuada dado su rol y actividades y 3) 5.2.1 permite detectar la similaridadde actividades entre dos colaboradores, dicho mecanismo permitira ofrecer informacion entrecolaboradores dada sus actividades actuales o potenciales.

El escenario 4.9 tiene como objetivo notificar usando diferentes modalidades. Este escenariose puede implementar parcialmente al usar los siguientes dos mecanismos: 1) 5.2.7 para conoceren donde se encuentra el colaborador y ası determinar si esta solo o acompanado, y 2) 5.2.1para determinar si la actividad del colaborador que genera la actividad esta relacionada con laactividad del que potencialmente recibira dicha notificacion.

Ver. Anterior Se propone un marco conceptual para orientar a los desarrolladores con aplica-ciones adaptativas al contexto considerando una meta-IU con o sin negociacion. La adaptacionconsiderada incluye el contexto de uso, la remodelacion y la redistribucion, sin dejar de lado laproduccion de los colaboradores ya que se propone un modulo para la recuperacion del sistema

Algunos componentes del contexto de uso es el medio de contacto y a la disponibilidad,los cuales resultan interesantes de analizar cuando el sistema interviene para establecer demanera automatica las opciones disponibles. El medio de contacto ofrece a cada colaborador lasherramientas disponibles para ser contactado, dependiendo de algunas caracterısticas propias(plataforma, disponibilidad, actividad y el tiempo final de la actividad actual) del colaboradorası como de los colegas que desea contactarlo. El estado de disponibilidad de un colaboradordepende de la similitud entre su actividad y la de sus colegas (cf. Escenario 4.6).

Usando las dimensiones propuestas en la seccion 2.9 del capıtulo 2, las cuales se refierena: mono-entidad o multi-entidad, variables contextuales y tipo de adaptacion (presentacion,ejecucion y aumentacion), sobre el diagrama de clases. En este capıtulo se puede concluir queuna mınima parte del diagrama considera la mono-entidad, en especifico para la asignacion deroles o la disponibilidad, ya que se considera a cada colaborador por separado. En cambio,la gran parte del diagrama considera la situacion de varias entidades de forma simultanea,e.g., un documento formado por varios objetos compartidos es creado a partir de uno o varioscolaboradores y la interfaz de usuario de cada colaborador se puede ver restringido por la

170 Conclusiones y trabajo a futuro

plataforma de los colaboradores y sus actividades que cada uno este desempenando al momentode contactar a un colega. Las variables contextuales que intervienen en la propuesta de lossistemas de cooperativos adaptativos (ver diagrama de clases) son varias, e.g., para establecerel medio de contacto se requiere conocer la plataforma, la actividad, la disponibilidad del grupode colaboradores y la fecha actual, por otra parte la accion de los colaboradores puede servirpara que la aplicacion detecte cuando dos o mas colaboradores estan haciendo referencia sobreun mismo objeto compartido, otro ejemplo es cuando la aplicacion requiere conocer tanto el roldel colaborador para mostrar las herramientas relacionadas, finalmente las condiciones grupalespermiten mostrar si los colaboradores trabajan de manera colocalizada o distribuida.

Analizando el tipo de adaptacion (presentacion, ejecucion y aumentacion) sobre la prop-uesta presentada podemos concluir que se aplican todos los tipos de adaptacion en diferentessituaciones, El tipo presentacion es aplicado cuando se proporcionan los medios de contactopara establecer comunicacion con un colaborador, en este caso el sistema presenta solo aquellasopciones que estan disponibles para ambos colaboradores. El tipo ejecucion se lleva a cabocuando el sistema asigna de manera automatica el rol, la disponibilidad y el medio de contacto.Finalmente, la informacion aumentada se proporciona cuando el sistema detecta que dos omas usuarios estan haciendo referencia a un objeto compartido, e.g., un colaborador describeun diagrama y otro modifica el mismo diagrama, otro ejemplo de la informacion aumentadacorresponde cuando dos o mas usuarios ligan un objeto compartido, en este caso ellos puedentener a la vista dicho objeto al dar clic sobre la liga.

7.2 Trabajo a futuro

El trabajo que falta para terminar este tema de tesis es el siguiente:

• Enriquecer el diagrama de clases del contexto de uso con los demas escenarios, hasta elmomento solo se han agregado dos escenarios

• Revisar el marco conceptual

• Crear las aplicaciones de prueba

• Modificar el articulo rechazado con las propuestas indicadas, con el objetivo de someterloa una revista.

• Escribir la tesis

Apendice A

Publicaciones

Publicaciones en revistas indexadas

• Dominique Decouchant, Sonia Mendoza, Gabriela Sanchez, Jose Rodrıguez, “Adaptinggroupware 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 Sanchez, ”A framework for developing context-aware applications for co-located collaborative work”, CCE, Mexico, D.F. (Mexico),September 30 - October-4, 2013.

• Sonia Mendoza, Dominique Decouchant, Gabriela Sanchez, Jose Rodrıguez and AlfredoPiero Mateos Papis, ”User Interface Plasticity for Groupware”, In Proceedings of theInternational Conference on Digital Information and Communication Technology and itsApplications (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 Sanchez, Sonia Mendoza, Dominique Decouchant, Lizbeth Gallardo-Lopez, andJose Rodrıguez, ”Plasticity of Interaction Interfaces: the Study Case of a CollaborativeWhiteboard”, In Proceedings of the 16th Collaboration Researchers’ International Work-shop in Groupware (CRIWG’2010), LNCS 6257, Springer, pp. 265-280, Maastricht (TheNetherlands), 20-23 September 2010.

Publicaciones en congresos nacionales

• Gabriela Sanchez, Sonia Mendoza y Dominique Decouchant, ”Adaptacion por plasticidadde sistemas de computo interactivos, ”VII Encuentro Participacion de la Mujer en la

171

172 Publicaciones

Ciencia, Centro de Investigaciones en Optica, ISBN 978-607-95228-1-0, 5 paginas, LeonGuanajuato (Mexico), Mayo 2010.

Participacion

• Consorcium doctoral, 16th Collaboration Researchers’ International Workshop in Group-ware (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., andSteggles, 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 applicationsto 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 PlasticWeb Site, Plastic Services for Mobile Devices (PSMD), Workshop hel in con- junction withInteract’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 EuropeanSymposium, 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 DesignFramework for Safety Critical Interactive Systems, Interacting with Computers, ElsevierScience 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 Sup-ported Collaborative Writing, Sharples, M. (Eds.), Springer-Verlag, pp. 87-112, 1993.

[Buzzi et al., 2010] Buzzi, M. C., Buzzi, M., Leporini, B., Mori, G. and Penichet, V.,AccessingGoogle docs via screen reader, Proceedings of the 12th international conference on Comput-ers 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. Demeureand J.-S. Sottet, Metamorphose des IHM et Plasticite: Article de synthese, Ergo’IA 2006,pp. 11-18, 2006.

173

174 REFERENCIAS

[Calvary et al., 2004] G. Calvary, J. Coutaz, O. Dassi, L. Balme and A. Demeure, Towards aNew 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., Thevenin, D., Limbourg, Q., Bouillon, L., Van-derdonckt, J., A Unifying Reference Framework for Multi-Target User Interfaces; Interact-ing 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., BouillonL., Florins M. and Vanderdonckt J., Plasticity of User Interfaces: A Revised ReferenceFramework,TAMODIA 2002: Proceedings of the First International Workshop on TaskModels and Diagrams for User Interface Design, pp. 127-134, 2002

[Calvary et al., 2001] G. Calvary, J. Coutaz and D. Thevenin, A Unifying Reference Frameworkfor 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 Adaptationin 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 Computer-Supported Collaborative Writing Implications for System Design, In Cooperative SystemsDesign, IOS Press, pp. 139-154, 2002.

[Churchill et al., 2004] Churchill, E.F., Nelson, L., Denoue, L., Helfman, J., Murphy, P., Shar-ing 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 Inter-face Plasticity, book The Human-Computer Interaction, Handbook: Fundamentals, Evolv-ing Technologies, and Emerging Applications, Ed. Human Factors and Ergonomics, 2007.

[Crease, 2001] M. Crease, A Toolkit of Resource-Sensitive, Multimodal Widgets, PhD Thesis,Department of Computing Science, University of Glasgow, 2001.

Decouchant, et al., 2013 Decouchant:13 Decouchant, D., Mendoza, D., Sanchez. G. andRodrı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: APlastic Slides Viewer, Plastic Services for Mobile Devices (PSMD), Workshop hel in con-junction with Interact’05, pp. 1-2, Rome (Italy), 2005.

[Derntl and Hummel, 2005] Derntl, M. and Hummel, K., Modeling Context-Aware e-LearningScenarios, Third IEEE International Conference on Pervasive Computing and Communi-cations 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 forsupporting 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 inShared Workspaces,Proceedings of the ACM Conference on Computer-Supported Coop-erative 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 The-sis, Department of Computer Science, University of London, June 1996.

[Ejigu et al., 2007] Ejigu, D., Scuturici, M. and Brunie, L., An Ontology-Based Approach toContext Modeling and Reasoning in Pervasive Computing, Pervasive Computing and Com-munications 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 forReal-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 RiverNJ (USA), 1995.

[Gauch, et al., 2007] Gauch, S., Speretta, M., Chandramouli, A. and Micarreli, User profilesfor Personalized information Access, The Adaptive Web, Methods and Strategies of WebPersonalization, 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 Transactionson Graphics, Vol. 5, No. 2, pp. 79-109, 1986.

[Ghiani et al., 2009] Ghiani, G., Paterno, F., Santoro, C., and Spano, L. D. Ubicicero: Alocation-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 ClockWritten in Oz with the QTk toolkit, Costin Pribeanu and Jean Vanderdonckt (Eds), TA-MODIA, pp. 135-142, 2002.

[Granados, 2011] Granados, L., Integracion de los espacios de comunicacion, produccion y co-ordinacion en un entorno cooperativo, Master thesis, Departament of Computation, Centrode Investigacion y Estudios Avanzados del IPN, December, 2012.

[Grudin, 1988] Grudin, J., Why CSCW Applications Fail: Problems in the Design and Evalua-tion of Organizational Intserfaces, In Proceedings of the Second Conference on Computer-Supported 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 aware-ness in educational groupware. Proceeding CSCL ’95 The first international conference onComputer support for collaborative learning, Indiana (USA), pp.147-156, 1995.

[Utwin et al., 1996] Gutwin, C., Greenberg, S., and Roseman, M., Workspace awareness sup-port 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 Coop-erative Information Systems, Vol. 19, Nos. 1 & 2, pp 71-120, World Scientific PublishingCompany, 2010.

[Henricksen et al., 2002] Henricksen, K., Indulska, J. and Rakotonirainy, A., Modeling ContextInformation in Pervasive Computing Systems, Pervasive Computing In Pervasive Comput-ing, 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 anarchitecture for context-aware group recommendations, In Kolf- schoten, G. L., Herrmann,T., and Lukosch, S. (Editors), CRIWG 2010 Collaboration and Technology - 16th Interna-tional 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: asurvey, IEEE International Workhop on Human Computer Interaction in Conjuntion withICCV 2005, pp. 1- 16, Beijing, China, 2005.

[Kofod-Petersen and Cassens, 2006] Kofod-Petersen, A. and Cassens, J.,Using activity theoryto model context awareness, Lecture Notes on Artificial Intelligence In Modeling and Re-trieval of Context, Vol. 3946, pp. 1-17, Springer Verlag, 2006.

[Kouadri and Brezillon, 2004] Kouadri, G. and Brezillon, P., Modeling Context-Based SecurityPolicies with Contextual Graphs, Second IEEE Annual Conference on Pervasive Computingand 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 forquality 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 MobilePhones for Brainstorming, In Proceedings of the 12th international conference on Humancomputer 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., Runtimetransformations for modal independent user interface migration, Interacting with Comput-ers, 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 co-laborativos, Master thesis, Departament of Computation, Centro de Investigacion y EstudiosAvanzados 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 envi-ronment for the conception and production of scientific publications, Proceedings of the2010 14th International Conference on Computer Supported Cooperative Work in Design,CSCWD 2010, Shen, W., Gu, N., Lu, T., Barthes, 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 Di-agrammatic Notation for Specifying Task Models, In INTERACT ’97: Proceedings of theIFIP 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-deviceuser interfaces, In proceedings of the ACM SIGCHI Symposium on Engineering InteractiveComputing 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., Mantyjarvy, J., Mori, G., Sansone, S., Author-ing 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 disappearand interaction evolves, Computer, Vol. 37, No. 12, pp. 47-54, 2004.

[Pinelle et al, 2008] Pinelle, D., Stach, T. and Gutwin C., TableTrays: Temporary, reconfig-urable work surfaces for tabletop groupware, Third IEEE International Workshop on Table-tops 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, No9, pp. 17-18, September 1994.

[Rekimoto and Saitoh, 1999] Rekimoto J., Saitoh M., Augmented Surfaces: a Spatially Con-tinuous Work Space for Hybrid Computing Environments, In Proceedings of Conference onHuman 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 MultipleComputer Environments. In Proc. of UIST97, ACM Press, pp. 31-39, 1997.

[Romero et al., 2013] Romero, M., Mendoza, S., Sanchez, G., A framework for developingcontext-aware applications for co-located collaborative work, CCE, Mexico, D.F. (Mexico),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 thetwenty-sixth annual SIGCHI conference on Human factors in computing systems, pp. 1759-1768. Florence (Italy), 2008

[Sendin et al., 2008] Sendin, M., Lopez-Jaquero, V., Collazos, C. A., Collaborative ExplicitPlasticity Framework: a Conceptual Scheme for the Generation of Plastic and Group-AwareUser 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: AClient-Side Generic Framework for Collaborative Activities., Y. A. Dimitriadis, I. Zigursand E. Gomez-Sanchez (Eds), CRIWG, pp. 219-227, 2006.

[Sendın and Lores, 2004] Sendın, M. and Lores, J., Plasticity in mobile devices: a dichotomicand semantic view, Workshop Engineering Adaptive Web, pp. 58-67, 2004.

[Serafini and Bouquet, 2004] Serafini, L. and Bouquet, P., Comparing formal theories of contextin 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., Klockner, K., Kolvenbach, S.,Supporting the Distributed German Gov-ernment 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 Ontologyfor Situation-Aware Social Networking, 3rd Workshop on Artificial Intelligence Techniquesfor 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 basedon UsiXML, In ICMI ’05: Proceedings of the 7th international conference on Multimodalinterfaces, pp. 259-266, 2005.

[Streitz et al., 1999] Streitz, N., Geibler, J., Holmer, T., Konomi, S., Moller-Tomfelde, C.,Reischl, W., Rexroth, P., Seitz, P., Steinmetz, R. i-LAND: An interactive Landscape forCreativity and Innovation, In Proc. of the ACM conf. On Human Factors in ComputerHuman Interaction (CHI99), ACM, pp. 120-127, 1999.

REFERENCIAS 179

[Tandler et al., 2001] Tandler, P., Prante, T., Muller-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 softwareand technology, ACM, pp. 11-20, New York, NY (USA), 2001.

[Thevenin and Coutaz, 1999] D. Thevenin and J. Coutaz, Plasticity of User Inter-faces: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 Gonzalez-Calleros, 2008] Vanderdonckt, J. and Gonzalez-Calleros, J.,Task-Driven Plasticity: One Step Forward with UbiDraw, pp. 181-196, In Proc. of the 2ndConference on Human-Centered Software Engineering and 7th International Workshop onTask 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 implementationof scientific collaborative editing environment on chemistry, Eighth International Conferenceon Grid and Cooperative Computing (GCC),pp. 188-92, Lanzhou, Gansu (China), 2009.

[Yongwu and Haake, 1999] Yongwu, M. and Haake, J., Supporting Concurrent Design inSCOPE, In The International Journal of Concurrent Engineering Research and Applica-tions, Vol. 7, No. 1, pp. 55-65, Technomic Publishing Co., Inc., March 1999.

Documents

XARE: Marco de desarrollo para sistemas colaborativos ... · de dispositivos fijos y móviles (e.g., pizarrones electrónicos, tabletas digitales, PDAs y smart-phones) impone nuevos