XARE: Marco de desarrollo para sistemas colaborativos … · 2014-08-28 · CENTRO DE INVESTIGACION Y DE ESTUDIOS´ AVANZADOS DEL INSTITUTO POLITECNICO´ NACIONAL UNIDAD ZACATENCO

CENTRO DE INVESTIGACION Y DE ESTUDIOS

AVANZADOS DEL INSTITUTO POLITECNICONACIONAL

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

Directores 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 humano-computadoraesta confinada en un solo dispositivo de computo (e.g., una PC) donde el usuario emplea dis-positivos de entrada/salida tradicionales (e.g., monitor, teclado y raton). Sin embargo, lacreciente proliferacion de dispositivos de computo y el progreso de las redes de comunicacionpotencialmente transforman al usuario en un ente que se desenvuelve en un ambiente vari-able y que utiliza simultaneamente varios dispositivos de computo, con el fin de satisfacer susnecesidades. Esta variedad de dispositivos fijos y moviles (e.g., pizarrones electronicos, tabletsdigitales, PDAs y telefonos inteligentes) impone nuevos requerimientos a las aplicaciones, comola propiedad de adaptarse a cambios contextuales. Esta propiedad ha sido principalmente ex-plorada en sistemas mono-usuario, generando la identificacion de siete dimensiones entre lasque destaca el contexto de uso definido en terminos del usuario, de la plataforma y del en-torno. Es sabido que la creacion de aplicaciones mediante un marco de desarrollo permiteque dichas aplicaciones adquieran “facilmente” algunas de las caracterısticas definidas en elmarco. Los pocos marcos de desarrollo, enfocados en adaptar a los sistemas colaborativos acambios contextuales, han tomado algunas de las siete dimensiones disenadas para los sistemasmono-usuarios sin realizar ninguna modificacion sobre estas. La contribucion de este trabajo deinvestigacion se enfoca en dos aspectos principales. El primero provee la definicion de contextode uso de los sistemas colaborativos, la cual incluye el grupo de colaboradores, el conjuntode dispositivos en uso, ası como el entorno compartido, el cual puede ser fısico o virtual, e.g.,documentos electronicos. El segundo aspecto involucra la creacion de un marco de desarrollollamado XARE (conteXt-Aware groupwaRE) que facilita la creacion de sistemas colaborativossensibles al contexto, considerando cinco de las siete dimensiones previamente mencionadas.Este marco esta acompanado por un conjunto de clases y mecanismos y fue creado a partirde un conjunto de escenarios y aplicaciones que nos permitieron expresar diversos tipos deadaptaciones.

Palabras claves: Plasticidad de las interfaces de usuario, contexto de uso, remodelacionde las interfaces de usuario, Interaccion Humano-Computadora, sistemas colaborativos, marcosplasticos.

iv

Abstract

Currently, most of the applications assume that human-computer interaction is confined to asingle computing device (e.g., a PC) where the user employs traditional input/output devices(e.g, monitor, keyboard and mouse). However, the increasing proliferation of computing devicesand the progress of communication networks potentially transform the user into an entitythat operates in a changing environment and simultaneously uses various computer devicesin order to satisfy his needs. This variety of stationary and mobile devices (e.g., electronicwhiteboards, tablets, PDAs and smartphones) imposes new requirements on applications suchas the capacity to adapt themselves to contextual changes. Adaptability has been mainlyexplored in single-user systems, leading to the identification of seven dimensions, among whichthe context of use defined in terms of the user, platform and environment is highlighted. It isknown that the creation of applications using a development framework allows such applicationsto acquire some of the features defined in the framework. The few development frameworksfocused on adapting groupware systems to contextual changes have taken some of the sevendimensions designed for single-user systems without applying any modification on them. Thecontribution of this research work is focused on two main aspects. The former one provides thedefinition of the context of use for groupware systems by including the group of collaborators,the set of devices in use and the shared environment, which can be physical or virtual, e.g,electronic documents. The latter aspect refers to the creation of a development framework calledXARE (conteXt-Aware groupwaRE) that facilitates the creation of context-aware groupwaresystems by considering five of the seven dimensions previously mentioned. This framework isaccompanied by a set of classes and mechanisms and was created from a set scenarios andapplications that allowed us to express several types of adaptations.

Key words: plasticity of user interfaces, context of use, remodelation of user interfaces,human-interaction computer, collaborative systems, plastic frameworks.

v

Agradecimientos

CONACYT y CINVESTAV:Gracias por su apoyo para la re-alizacion de esta tesis.

Dra. Sonia G. Mendoza y Dr.Dominique Decouchant: Gra-cias por su confianza, paciencia,apoyo y comprension en el desar-rollo de esta tesis.

Mami: Gracias por ser la mamaque eres, gracias por dedicarnostu vida a mi y a mis her-manos. Gracias por ser fuertecomo un padre y carinosa comouna madre. Gracias por contin-uar luchando dıa a dıa. Te amoChinitos.

A mis hermanos: Rosy y Danygracias por cuidarme desde losprimeros dıas de mi vida. Rebe,Aby y Maru gracias por apoyarmeen todo momento.

Gracias Pedro Miranda, Ivan M.Romero, Laura Granados y San-dra B y a los chicos de colima(Alex, y Gris) por su apoyo en larealizacion de esta tesis.

vi

Gracias Sofia, Erica y Felipa porbrindarme su comprension, porser mis amigas cuando mas lasnecesite. Gracias Jose Luis, y Dr.Santiago por su apoyo.

Creo que he visto un Baquero,gracias por tus consejos Rafa.Gracias Amilcar por todos losconsejos profesionales y person-ales que me has brindado todoeste tiempo.

Gracias Kim, Ivone, Cheche, Dr.Guadalupe y mis companeros delCINVESTAV.

Gracias Gabriel, Lobatos yErnesto por escucharme, apo-yarme y hacerme reir en todomomento.

Gracias Saad por todo.

Gracias a todas las pesonas queen algun momento compartieronconmigo parte de esta aventura enel CINVESTAV.

vii

Dedicatoria

† Marıa Eugenia Morales Aguilar

Esta tesis se la quiero dedicar a mi mama, Marıa Eugenia Morales Aguilar, por que ella fue yha sido un ejemplo a seguir, por que cada una de tus lecciones las llevaste a cabo, por ejemplo:seguir en pie frente a la vida sin importar las adversidades, ya que hasta el ultimo dıa de tuvida tu luchaste.

Recuerdo que cuando eramos pequenos mis hermanos y yo solias contarnos cuentos antes dedormir, la mayorıa train moraleja, incluso muchos de esos cuentos los cambiabas tu para quenos dieras una leccion de vida.

Se que si hubieses vivido mas tiempo me hubieses ensenado mas cosas, pero era tiempo quete fueras y te agradezco todo el tiempo que me diste, espero yo algun dıa ser como tu.

Tu sabes el esfuerzo que hubo detras de esta tesis, por eso quiero dedicartela. Te amo mama,yo se que estas palabras las escuchaste muchas veces, pero no me cansare de decirlas aun cuandoya no estes aquı.

viii

Indice general

Indice de figuras ix

Indice de tablas xi

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

ix

x INDICE GENERAL

2.6 Cobertura del contexto de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.7 Cobertura de espacio tecnologico . . . . . . . . . . . . . . . . . . . . . . . . . . 35

2.8 Meta-interfaz de usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

2.10 Sıntesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

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 Explıcita 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 Sıntesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

INDICE GENERAL xi

4 Analisis de requerimientos del marco XARE 73

4.1 Contexto de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

4.1.1 Contexto de uso de los sistemas mono-usuario . . . . . . . . . . . . . . . 74

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

4.2 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

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

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


4.4.3 Editor de mapas mentales . . . . . . . . . . . . . . . . . . . . . . . . . . 93

4.5 Escenario 3: Redistribucion de una aplicacion colaborativa . . . . . . . . . . . . 97

4.5.1 Preambulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97


4.5.3 Herramienta de votacion . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

4.6 Escenario 4: Mejoramiento de la conciencia grupal . . . . . . . . . . . . . . . . . 106

4.6.1 Preambulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106


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

4.7 Escenario 5: Manejo de intromisiones . . . . . . . . . . . . . . . . . . . . . . . . 113

4.7.1 Preambulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113


4.8 Escenario 6: Suministro de informacion relevante . . . . . . . . . . . . . . . . . 115

4.8.1 Preambulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115


xii INDICE GENERAL

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

4.9 Escenario 7: Notificaciones multi-modales . . . . . . . . . . . . . . . . . . . . . 120

4.9.1 Preambulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120


4.10 Sıntesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

5 Diseno del marco XARE 125

5.1 Diagramas de clases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

5.1.1 Contexto de uso de los sistemas colaborativos . . . . . . . . . . . . . . . 126

5.1.2 Componente observador . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

5.2 Mecanismos del marco XARE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

5.2.1 Mecanismo de similitud de actividades . . . . . . . . . . . . . . . . . . . 134

5.2.2 Mecanismo de disponibilidad de un colaborador . . . . . . . . . . . . . . 136

5.2.3 Mecanismo de medios de contacto . . . . . . . . . . . . . . . . . . . . . . 138

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

5.2.5 Mecanismo para la creacion de referencias deıcticas . . . . . . . . . . . . 141

5.2.6 Mecanismo de proximidad logica . . . . . . . . . . . . . . . . . . . . . . 143

5.2.7 Mecanismo ubicacion fısica . . . . . . . . . . . . . . . . . . . . . . . . . . 145

5.3 Marco XARE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

5.4 Sıntesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150

6 Funcionamiento del marco XARE 153

6.1 Instancias del marco XARE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

6.2 API de comunicacion entre las capas . . . . . . . . . . . . . . . . . . . . . . . . 155

6.3 Sıntesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

7 Conclusiones y trabajo a futuro 163

7.1 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

7.2 Trabajo a futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

INDICE GENERAL xiii

A Publicaciones 171

Referencias 173

xiv 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

xv

xvi 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 . . . . . . . . . . . . 37

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

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

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

3.4 Marco para la 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

3.7 Arquitectura conceptual del Marco Generico de Contexto . . . . . . . . . . . . . 64

4.1 Relacion entre escenarios y aplicaciones colaborativas . . . . . . . . . . . . . . . 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 mensajerıa instantanea para referirse a unparrafo mostrado 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 mensajerıa instantanea para referirse a una figuramostrada en el editor colaborativo . . . . . . . . . . . . . . . . . . . . . . . . . . 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 xvii

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 Pantalla principal donde se muestran las aplicaciones disponibles y una barra decolaboradores que exhibe a los miembros ausentes y virtualmente presentes . . . 91

4.7 Pantalla para elegir a los participantes en la creacion del mapa mental y sus roles 92

4.8 Vista del mapa mental cuando un colaborador asume el rol de revisor . . . . . . 93

4.9 Vista del mapa mental cuando un colaborador asume el rol de autor . . . . . . . 94

4.10 Adaptabilidad de la interfaz de usuario del editor colaborativo de mapas mentalescon base en la configuracion del grupo, las dimensiones de la pantalla y el rol delusuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

4.11 Datos de la votacion en curso ingresados por el proponente en el pizarron interactivo 99

4.12 Adaptabilidad de la interfaz de usuario de la herramienta de votacion con baseen la configuracion del grupo y el rol del usuario . . . . . . . . . . . . . . . . . . 101

4.13 Resultados de la votacion mostrados a los participantes co-localizados en elpizarron interactivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

4.14 Resultados de la votacion mostrados en los dispositivos de los participantes dis-tribuidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

4.15 Disponibilidad y medios de contacto al inicio de la sesion colaborativa. . . . . . 109

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

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

5.2 Diagrama de clases del componente observador . . . . . . . . . . . . . . . . . . . 131

5.3 Mecanismo para determinar los medios de contacto de un colaborador . . . . . . 139

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

5.5 Mecanismo de referencias deıticas . . . . . . . . . . . . . . . . . . . . . . . . . . 142

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

5.7 Mecanismo de ubicacion fısica . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

5.8 Capas del marco XARE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

6.1 Instancias del marco XARE en los dispositivos moviles . . . . . . . . . . . . . . 154

xviii 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 Similitud entre las actividades de dos colaboradores . . . . . . . . . . . . . . . . 135

5.2 Estados de disponibilidad de un colaborador percibidos por sus colegas . . . . . 137

5.3 Proximidad logica entre dos colaboradores en un espacio de trabajo compartido 145

5.4 Sugerencias de mecanismos para implementar las aplicaciones de algunos esce-narios analizados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

6.1 API de la comunicacion entre instancias del marco XARE . . . . . . . . . . . . 155

6.2 API de la capa de espacio de trabajo . . . . . . . . . . . . . . . . . . . . . . . . 156

6.3 API de la capa de adaptacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

6.4 API de la capa de deteccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

xix

xx 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 enMassachussets 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 versionesen multiples dispositivos heterogeneos. La propiedad de “plasticidad” pretende hacer frente a

8 Introduccion

estos 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 elementosdel contexto de uso (i.e., usuario, entorno y plataforma), solo unos cuantos consideran alguna

Capıtulo 1 9

forma 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.

Dado el planteamiento del problema podemos generar la siguiente hipotesis:

Es posible definir un contexto de uso para los sistemas colaborativos que considere las carac-terısticas propias de los entornos colaborativos, ası como crear un marco que facilite la creacionde sistemas colaborativos capaces de adaptarse a cambios contextuales.

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 interfacesde usuario plasticas. La mayorıa de estos escenarios son ejemplificados mediante aplicaciones.

12 Introduccion

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 ensistemas 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 en dosgrandes partes que se consideran relevantes para este trabajo de investigacion. La primera parteestudia las siete dimensiones de las interfaces plasticas propuestas en el dominio de los sistemasinteractivos mono-usuario (cf. seccion 2.1-2.8). La segunda parte analiza las dimensionesdesarrolladas en el ambito de los sistemas conscientes de contexto (cf. seccion 2.9). Paraejemplificar dichas dimensiones, se consideran varios sistemas interactivos, los cuales estanenfocados en apoyar el trabajo individual o el grupal. Finalmente, se presentan una sıntesis deeste 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 lapared, que forman un dispositivo largo y sensible al contacto. InteracTable es una pantalla


sensible al contacto colocada en la parte superior de una mesa. Finalmente, 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 desplieguedinamico significa que la remodelacion y la redistribucion se pueden realizar en tiempo deejecucion [Vanderdonckt, et al., 2008].

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

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]).

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).

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

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]).

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 crearun 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.

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


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

Capıtulo 2 35

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

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 IU


Dos o mas teléfonos celulares forman unespacio

Figura 2.25: Adaptacion a la plataforma en el sistema MindMap

en 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]—,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 usuarios

Capıtulo 2 37

finales 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 alsitio 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.

Capıtulo 2 39

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, enparticular 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.

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 sistemas


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

cooperativos, 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 estanacoplados. 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.

2.10 Sıntesis

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 el

Capıtulo 2 41

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

usuario 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 sistemasplasticos

En este capıtulo se presentan siete marcos (frameworks) que fueron seleccionados por ser losmas representativos del tema de investigacion. Por cada marco se proporciona una brevedescripcion con la finalidad de resaltar sus caracterısticas mas importantes. Los dos primeros,RUIUM-O y CAMELEON-RT, facilitan el desarrollo de sistemas mono-usuario, mientras quelos restantes estan enfocados en el desarrollo de sistemas colaborativos. A nuestro saber, elmarco RUIUM-O es el primero en considerar el contexto de uso, y la meta interfaz de usuarioy algunos percutores de plasticidad en la creacion de interfaces de usuario (cf. Seccion 3.1). Elmarco CAMELEON-RT tambien considera el contexto de uso, ası como la redistribucion y lamigracion de la interfaz de usuario (cf. Seccion 3.2).

El marco 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. Seccion3.5), RCCG (cf. Seccion 3.6) y GC (cf. Seccion 3.7) se enfocan solo en el contexto de uso,dejando de lado las demas dimensiones de la plasticidad.

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 presentauna sıntesis del presente capıtulo, las cuales exhiben las posibles tendencias de dichos marcos.

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 partirde los modelos de evolucion y transicion. El modelo de evolucion (O6) indica alos sistemas interactivos cuando deben adaptarse a cambios de contexto, mientras que elmodelo de transicion (O7) tiene como objetivo suavizar discontinuidades entre dichoscambios.

Losmodelos 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 los modelos de tareas

y conceptos (T1), como las interfaces de usuario abstractas (T2) y concretas (T3)necesarias 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 tareas.

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


Los espacios de trabajo, e.g., la temperatura de los cuartos de una casa, son inferidos a partir delas relaciones de las tareas que fueron previamente expresadas en los modelos de conceptos

(I1) y tareas (I2). Los espacios anteriores, los cuartos de una casa, son representaciones deuna 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 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 (IUFinal). La transformacion horizontal corresponde a la translacion entre modelos del mismonivel, en donde la “translacion” significa una operacion que transforma la descripcion de unobjetivo particular en otra descripcion de la misma clase, pero con diferente objetivo. Unaoperacion cruzada significa tanto trasladarse a otro contexto de uso como cambiar el nivelde reification. Todas las operaciones de transformacion pueden ser ejecutadas de manera au-tomatica o manual. La IU final es generada a partir de la IU concreta y es expresada encodigo fuente, e.g., Java o HTML. Dicha IU final soporta adaptacion dinamica multi-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 de “regular”a “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 cambios deplataforma (e.g., pasar de una PC a una PDA), cambios de entorno (e.g., encender la luz porqueel cuarto esta muy obscuro) o cambiar de codigo ejecutable debido a que el codigo actual nosoporta el cambio de contexto. Finalmente, la ejecucion de la reaccion involucra la realizacionde 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).

Losmodelos observadores conducen la adaptacion en tiempo de ejecucion. Tanto losmod-

Capıtulo 3 47

elos ontologicos Oj como los arquetıpicos Ij pueden ser referenciados por la infraestructuraen tiempo de ejecucion o por la IU final (ver Figura 3.1), los cuales estan encargados de laetapa de adaptacion (reconocimiento de la adaptacion, calculo y ejecucion de la 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 unmodelo de dialogo, los cuales no son considerados en el marco analizado. El modelo de

presentacion especifica aspectos de la presentacion de la IU en terminos abstractos, ası como lainvocacion de ellos, e.g., en un metodo se especifica como presentar graficamente las propiedadesde un avion. El modelo de dialogo contiene la descripcion del comportamiento y la inter-accion de las 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 dialogo, sino tambien incluye el modelo de

aplicacion. Este modelo sirve para dar acceso a los metodos de las clases contenidas enel 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


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


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

Tiempo deejecucion

Contexto de uso: plataforma

TERESA


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 considera esta componente, pero la herramienta no

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 asociacion de los metodos con los eventos, e.g., despliegue de un menu medianteun clic derecho sobre un avion y c) la respuesta a los metodos 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),tareas (I2) y plataforma (I4). La metodologıa TERESA recomienda empezar por hacerdescripciones de las tareas, e.g., “apagar la luz”.

Los modelos transitorios corresponden al modelo de tareas y conceptos (T1), IU

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

SEESCOA incluye solo las interfaces de usuario (T2-T4) en la etapa de modelos transito-rios; la IU abstracta (T2) es generada a partir de los modelos de presentacion, dialogo,plataforma y dispositivos. En esta herramienta no se incluye el modelo de tareas debido

Capıtulo 3 49

a que las tareas de un usuario no cambian durante el proceso de adaptacion.

TERESA genera modelo de conceptos y tareas (T1) mediante los modelos de

conceptos (I1) y tareas (I1) pertenecientes a los modelos iniciales. La IU abstracta (T2)es generada a partir de los modelos de presentacion, dialogo y 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 interfaz de usuario,permitiendo que el desarrollador 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 la 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 redistri-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 del usuario [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.

La capa de plataforma incluye tanto el hardware como el sistema operativo. El hardware


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

Sistema operativo

Sistema interactivoIn

frae

stru

ctura

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

se 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).

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 de

Capıtulo 3 51

abstraccion, 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 nuevoscomponentes, estos son recuperados del espacio de almacenamiento por el administradorde componentes.

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].



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 pocketPC (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 tresgrupos de componentes: 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 compo-nentes, ya que posee una infraestructura para descubrir cambios en la plataforma, oculta laheterogeneidad del hardware (PC y PDA) y soporta la migracion de la interfaz de usuario.Por otro lado, CamNote implementa los siguientes componentes del tercer grupo: el motor de

evolucion mediante reglas determinadas por el desarrollador y el configurador de situaciona traves de una tecnica de recuperacion de datos. Ademas, CamNote crea una nueva situacion(a partir del sintetizador de situacion) en respuesta a la llegada o salida de una pocketPC.

3.3 Marco de Plasticidad Implıcita

El marco de Plasticidad Implıcita (PI) [Sendın and Collazos, 2006] tiene 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 ladodel 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.

Capıtulo 3 53

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 Explıcita Colaborativa

Sendin et al. proponen un marco conceptual llamado Plasticidad Explıcita Colaborativa (PEC)[Sendın and Lores, 2004]. El termino de “plasticidad explıcita” se refiere a la capacidad degenerar automaticamente una interfaz de usuario especıfica para un contexto de uso, em-pezando de una especificacion abstracta. Para lograr la generacion automatica de dicha in-terfaz se requiere de una maquina EPE (Explicity Plasticity Engine) en la etapa de diseno[Sendın and Collazos, 2006].

El marco PEC se ubica del lado del servidor para llevar a cabo las adaptaciones necesariascuando un cliente haya iniciado una sesion o solicite una nueva adaptacion. Dicho marcoaborda tres puntos: 1) conciencia de grupo como un parametro de la plasticidad, 2) integracionde un mecanismo de conciencia tanto del lado del cliente como del lado del servidor y 3)integracion de una vista general del conocimiento compartido. Este ultimo se refiere a todoslos aspectos del trabajo colaborativo que pueden ser usados en el desarrollo de una actividad


grupal [Sendin et al., 2008].

3.4.1 Fases ARP, CRP, IMP y PIM

El marco PEC se divide en cuatro fases: 1) Abstract Rendering Process (ARP), 2) 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., dialogo,tarea, dominio y espacial. La fase ARP genera la Interfaz de Usuario Abstracta (IU

abstracta) usando los siguientes modelos: tarea, dominio, espacial, usuario, dialogo ygrupo. La fase CRP obtiene la Interfaz de Usuario Concreta (IU concreta) a partir dela IU abstracta; esta fase selecciona los componentes concretos de la interfaz de usuario quemejor representa la funcionalidad descrita por los componentes abstractos. Finalmente, la faseIMP genera la Interfaz de Usuario Final (IU final) a partir de la IU concreta y regresala IU final como codigo ejecutable o interpretable. Las fases ARP, CRP e IMP se componen devarios modelos, los mas representativos se mencionan a continuacion (cf. Figura 3.3):

• Modelo de tarea: es una representacion estructurada de las tareas que un usuario puedellevar a cabo mediante una interfaz de usuario;

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

• Modelo de usuario: representa las caracterısticas y los aspectos relacionados con unusuario, tales como el nivel de conocimiento, preferencias, objetivos, situacion, necesi-dades, etc.;

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

• Modelo espacial: es una descripcion detallada del mundo real que proporciona concien-cia de ubicacion;

• Modelo de plataforma: se refiere a una expresion explıcita de la plataforma de inter-accion en terminos de recursos fısicos y caracterısticas de software (e.g., sistema operativo,version de la maquina virtual de Java y configuracion);

• Modelo de entorno: 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;

• Modelo de grupo: es una representacion del conocimiento compartido; en este modelose considera una memoria de grupo, la cual se puede conceptualizar como una coleccionde percepciones individuales (conciencia de grupo).

Capıtulo 3 55

Figura 3.3: Marco conceptual de Plasticidad Explicita Colaborativa

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

1. IU abstracta : es la interpretacion de los conceptos de domino y funciones, los cualesson independientes de los interactores. Esta interfaz de usuario es generada en la faseARP;

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


IU abstracta;

3. IU final: es generada a partir de la IU concreta, 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 IU final es IMP (cf.Figura 3.3) ya que transforma el aspecto visual y dinamico de la IU concreta 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 IU abstracta a la IU concreta . 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:

• Modelo de tarea: usa tres diferentes notaciones, tales como diagrama de estado, modeloCTT, ademas de una herramienta de interaccion abstracta;

• IU abstracta: usa UMLi (Unified Modeling Language for Interactive Applications);

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

• IU final : es realizada por un traductor;

• Criterio de usabilidad: describe el peso y la importancia de cada criterio de usabili-dad.

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. Dentrode las organizaciones, los despliegues publicos se han utilizado para facilitar las tareas, la

Capıtulo 3 57

sincronizacion 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 explıcitas 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), enriquecimiento de la

presencia (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 elde 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 audienciase caracteriza por genero, se puede desplegar informacion relevante para mujeres cuando lamayorıa de la audiencia 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

individual de presencia (D2), el cual permite a los sistemas de despliegue minimizar larepeticion del contenido visto por cada usuario o identificar en que periodos de tiempo seencuentra la misma persona, ası como establecer una correlacion entre diferentes personas ogrupos (cf. componente de 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 expresansu interes respecto a un deporte, entonces el sistema podrıa mostrar el contenido relacionado

Capıtulo 3 59

con ese deporte en un momento dado.

El componente de 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 explıcita.

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

3.6 Marco y Arquitectura para Recomendaciones de

Conciencia de Contexto Grupal

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

La arquitectura propuesta se denomina Vistas de Contexto Hybreed. Hussein et al. utilizanel termino “vista de contexto” para referirse a un estado virtual que se genera a partir de unasecuencia de operaciones de contextualizacion. El contexto considera informacion externa a lascircunstancias (e.g, tiempo y lugar) e informacion derivada de la interaccion de los usuarios conel 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 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 usuario dio


clic sobre un ıcono. Esta clase esta ubicada en el servidor y recibe notificaciones, por parte decada cliente, acerca de algun cambio en el estado actual del usuario correspondiente, lo cual im-plica la actualizacion de dicho estado. La clase AdministradorDeEstado tambien puede recibirla peticion del estado global de un grupo, lo cual implica que el servidor solicite informacionde estado a cada cliente. Debido a que el estado global es la suma de los estados individuales,Hussein et al. sugieren un mecanismo de bloqueo para evitar un problema de concurrencia.Dependiendo de la configuracion realizada por los desarrolladores, el evento de actualizacionpodrıa desencadenar algunas operaciones de inferencia en el servidor .

La clase MecanismoDeSensado infiere informacion de 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 y globales yopcionalmente guarda el contexto del grupo. En el caso de los estados globales, el repositoriopodrıa usar sentencias para representar el estado de un grupo. Dichos datos se guardan en unservidor 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 parailustrar algunas recomendaciones. Dicho ejemplo puede ser reemplazado 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 activar nodos adyacentes que tienen ciertogrado 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., el uso de un filtro colaborativo para obtener ciertos elementos, los cualespueden utilizarse como mecanismos de activacion en el algoritmo de propagacion de laactivacion.

Bajo este marco se implemento la arquitectura propuesta, ası como la librerıa HybreedRecFlow. Dicha librerıa es una implementacion de la interfaz FlujoDeTrabajo, pero no sereporta el desarrollo de alguna aplicacion especıfica.

Capıtulo 3 61

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 este marco cubre as-pectos individuales como grupales. Este modelo abarca la conciencia de contexto y la adaptacional 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 yadaptacion

El marco GC esta dividido en cuatro capas: conocimiento, estado, contextualizacion yadaptacion (cf. Figura 3.6).

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

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 diferentes


aspectos del 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., la idea deque una persona esta en un cuarto (conocimiento abstracto), se deriva del hecho que Paulesta en el cuarto LF283 (conocimiento concreto). Las reglas de inferencia se encargande hacer la extraccion 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, lainformacion obtenida puede ser de varios tipos: de un usuario, de una situacion independiente,informacion neutral, informacion del sistema o informacion externa estatica, e.g., la capitalde un paıs. Este modelo contiene varias clases para el manejo de la comunicacion sıncrona yasıncrona por medio de audio, video y chat, conciencia sıncrona y asıncrona, administracion(e.g., sesion, concurrencia y usuario), ası como editores compartidos (e.g., texto, imagen ycalendario).

La capa de estado contiene informacion de la situacion actual, del entorno fısico y com-putacional, de los recursos y del usuario, e.g., ¿En donde esta el usuario? ¿Que hora es? y¿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 deconocimiento) para reflejar el estado individual y sus propiedades.

La capa de contextualizacion provee tecnicas que definen un subconjunto de un es-tado que es relevante para cierto enfoque, el cual es un subconjunto no vacio de objetos delmodelo de estado que representa en cierto momento, i. e., el centro de atencion del sistema.El enfoque sirve como entrada inicial para ejecutar las tecnicas de contextualizacion. Loscomponentes en esta capa corresponden a las reglas 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.

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 que

Capıtulo 3 63

accion de adaptacion se ejecuta en que caso. Las reglas de adaptacion incluyen operacionespara cambiar propiedades del entorno colaborativo 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,espacios de trabajo, tareas a resolver, actividades de los colaboradores y aplicaciones colabora-tivas.

Por otro lado los escenarios, representados por medio del lenguaje OWL (Web OntologyLanguage), estan divididos respecto a situaciones colaborativas tales como co-localizacion, co-acceso, co-recomendacion y co-dependencia. Cada escenario ejemplifica la situacion de dospersonas que colaboran en la redaccion de un documento. A continuacion se exponen los puntosimportantes a considerar en cada escenario: la deteccion tanto de los participantes que estanco-localizados como los dispositivos en uso (co-localizacion); la habilitacion de funcionalidadesen un sistema colaborativo con base en el rol de un colaborador (co-acceso); la recomendacionde informacion dada una solicitud previa (co-recomendacion) y la manipulacion de tareas, e.g.,la asignacion automatica o manual, las prioridades entre ellas, la fecha lımite y la dependenciaentre 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 de laadaptacion. En particular, el proceso de adaptacion del marco CG se puede representar de lasiguiente 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 tiene como entrada el modelo de estado (capa de estado),el cual es procesado por las reglas de contextualizacion, cuya tarea es establecer elestado 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 deadaptacion). 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 propiedades adaptativas.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 a cam-bios contextuales. En el lado derecho de dicha arquitectura, se muestran los componentes delmarco CG, mientras que en el lado izquierdo se representan los componentes de la aplicaciona extender. El marco GC esta compuesto por el 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

Otro modulo importante es el servicio de contexto, el cual accede y manipula el modulomodelo de contexto. Este esta conformado por los diferentes modelos del marco, e.g., modelode dominio, reglas de sensado y el modelo de estado.

En la arquitectura propuesta se debe habilitar primero el mecanismo de adaptacion para

Capıtulo 3 65

permitir cambios en las IU de la aplicacion por medio del componente de adaptacion.Dicho componente llama a las funciones de adaptacion, las cuales son proporcionadas por losdesarrolladores de la aplicacion. Despues de habilitar el mecanismo de adaptacion, se activael mecanismo de sensado para monitorear la interaccion entre el usuario y 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 en 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. Las interfaces mencionadas permiten trabajarsobre los componentes de la interfaz grafica de usuario, e.g., mostrar, ocultar y modificar loscomponentes.

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

Mediante la implementacion de la arquitectura, Haake et al. consideran que su marco GCpuede ser operacional. Aunque no crearon una aplicacion especıfica, realizaron pruebas fun-cionales a partir de cuatro escenarios relevantes que denotan situaciones tıpicas del trabajocolaborativo (co-localizacion, co-acceso, co-recomendacion y co-dependencia).

3.8 Analisis comparativo de los marcos analizados

En la Tabla 3.2 se analizan dos caracterısticas importantes de los marcos revisados. La primeraes conocer si los marcos estan disenados para desarrollar sistemas mono-usuario o colaborativos.En este caso se aprecia que tanto el marco RUIUM-O4 como CAMELEON-RT se enfocan ensistemas mono-usuario. En cambio, los marcos restantes (PI5, PEC6, ACCDP7, RCCG8 y GC9)se especializan en sistemas colaborativos; el marco PI tiene como objetivo ofrecer plasticidady conciencia de grupo a los sistemas colaborativos, mientras que el marco PEC combina laconciencia de grupo con la plasticidad. Por otro lado, el marco ACCDP pretende proveer deadaptacion de conciencia de contexto en despliegues publicos, lo cuales dan soporte al trabajo

3http://r-osgi.sourceforge.net/4Referencia Unificado para Interfaces de Usuario Multi-Objetivo5Plasticidad Implıcita6Plasticidad Explicita Cooperativa7Adaptacion de Conciencia de Contexto en Despliegues Publicos8Recomendaciones de Conciencia de Contexto de Grupo9Generico de Contexto


colaborativo.

Marco conceptual Colaborativo Implementacion

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ısticade abordar el trabajo tanto individual como grupal, ya que el primero tiene como objetivoproveer recomendaciones en ambos ambitos, en tanto que el marco GC puede ayudar a formarun contexto grupal a partir de aspectos individuales, e.g., determinar la ubicacion de cadausuario.

La segunda caracterıstica importante mostrada en la Tabla 3.2 se refiere a conocer si losmarcos ofrecen algun tipo de implementacion. El marco RUIUM-O no implementa ningunejemplo de prueba, sino que se probo al compararse con algunas herramientas, que siguen unametodologıa similar la sugerida en dicho marco. Por otro lado, CamNote y I-AM son apli-caciones creadas con base en el marco CAMELEON-RT. Dentro de los marcos para sistemascolaborativos, el marco PI se encuentra en vıas de implementacion, hasta el momento se encuen-tra en desarrollo la parte del servidor. Bajo el marco PEC se reporta la herramienta AB-UIEDque permite la produccion automatica de interfaces plasticas, para entornos mono-usuario yaque no se implementaron los modulos concernientes al soporte de la colaboracion, e.g., el mod-elo de grupo. Es importante hacer notar que no se reporta ninguna aplicacion desarrolladamediante la herramienta AB-UIED.

El marco RCCG ofrece librerıas y algunos algoritmos para proveer la recomendacion deconciencia de contexto, solo que no se reporta ninguna aplicacion que haga uso de dichaslibrerıas. Por otro lado, Haake et al., autores del marco GC, implementaron la arquitectura

Capıtulo 3 67

propuesta para unir el marco GC con aplicaciones colaborativas. A partir de los escenariosreportados, obtienen pruebas funcionales, las cuales son usadas para probar la implementacionde la arquitectura.

Por otra parte, como se menciono en el capıtulo 2, la implementacion de interfaces de usuarioplasticas multimodales generan un espacio del problema, e.g., adaptacion al contexto de uso,percutores de plasticidad, granularidad de la interfaz de usuario, granularidad del estado derecuperacion, etc. Hasta el momento, se consideran siete dimensiones que conforman dichoespacio del problema.

Una de las siete dimesiones de mayor relevancia para este trabajo de investigacion es ladimension contexto de uso, la cual considera la adaptacion al usuario, al entorno y a laplataforma sin perder un conjunto de criterios de calidad, e.g., la usabilidad. Dicha dimensionse analiza en la tabla 3.3. El marco RUIUM-O considera por completo la dimension contexto

de uso tanto en los modelos ontologicos como en los arquetıpicos; en este marco se consideraal usuario de manera general en sus modelos de usuario, ubicado en los modelos ontologicos yarquetıpicos; ademas podemos observar que existe el modelo de tareas para referirse a la tareadel usuario. En cambio, el modelo de plataforma permite hacer la descripcion de los dispositivosdisponibles, ası como clasificarlos en plataforma basica, e.g, computadora personal, o en clusters.El modelo de entorno contiene caracterısticas genericas para describir los entornos adyacentes.

El marco CAMELEON-RT abarca por completo el contexto de uso, i.e., considera alusuario, al entorno y a la plataforma. Dicho marco considera la plataforma, la cual estacompuesta por hardware (e.g., sensores y superficies de despliegue) y software (e.g., sistemaoperativo y 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. Este marco tambien abarca el entorno a par-tir de la infraestructura de contexto y el observador del lugar fısico para proveer unmodelo del lugar fısico; por ultimo abarca al usuario por medio del observador de usuario,el cual provee informacion relevante, e.g., perfil del usuario, su ubicacion y su posicion relativa.

El marco PEC considera por completo el contexto de uso, ya que representa al usuariomediante varios modelos, e.g., usuario, dominio y tarea, para tener conocimiento de sus car-acterısticas, e.g., conjunto de tareas que puede llevar a cabo, preferencias, objetivos, nivel deconocimiento, situaciones y necesidades. El marco PEC aborda la plataforma por medio delmodelo de plataforma para contabilizar los recursos fısicos, ası como las caracterısticas de soft-ware. Finalmente, el marco mencionado contempla al entorno mediante el modelo espacial yel de ambiente para obtener la descripcion del exterior, de tal manera que se pueda crear unaconciencia de ubicacion, tiempo (hora y dıa de la semana) y condiciones ambientales (luz deldıa, nivel de ruido ambiental y condiciones 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 de


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 de

conocimiento,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 yactividades

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

la 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 en

Capıtulo 3 69

las reglas de contextualizacion (capa de contextualizacion); el artefacto que los colaboradoresestan manipulando en un momento dado, la formacion de grupos, varios aspectos de la tarea,tales como la tarea a resolver, las prioridades entre ellas, el tiempo lımite, la dependenciaentre ellas y la asignacion automatica o manual; el rol y aspectos dependientes del rol, comolos permisos de acceso, y las actividades de los colaboradores. En el caso de la dimensionplataforma se considera las aplicaciones y el uso de diferentes dispositivos. Finalmente, estemarco considera varios aspectos de la dimension entorno compartido, e.g., consideracion delartefacto, deteccion de los participantes, tiempo (hora actual), co-localizacion, y las accionespermitidas en las aplicaciones con base en el rol.

Tanto el marco ACCDP como el marco RCCG abordan parcialmente el contexto de uso,ya que no incluyen a la plataforma. El marco ACCDP se centra en el usuario, ya que detectala presencia de los usuarios, e.g., edad, genero y preferencias, mediante las huellas digitales,la identificacion y el enriquecimiento de la presencia. Por su parte, el marco RCCG considerael estado del usuario mediante las clases AdministradorDeEstado, MecanismoDeSensado, entreotras para inferir la ubicacion o conocer el elemento de la interfaz de usuario que ha sidoseleccionado. El entorno es abordado por el marco ACCDP, ya que puede detectar la cantidadde personas en un lugar, el genero, etc, ası como la sugerencia de contenido de un grupomediante la caracterizacion de huellas digitales y sugerencia de contenido. El marco ACCDPaborda el entorno cuando proporciona el trabajo a miembros de un grupo por medio de losalgoritmos 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 la interfaz de usuario, e.g., nivel de luz.

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

de plasticidad, granularidad de adaptacion, 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 el modelo de evolucion;por lo tanto podemos decir que este marco implementa la migracion, pero no especifica siimplementa la remodelacion o la redistribucion. Por otro lado, el marco CAMELEON-RTimplementa parcialmente el percutor de plasticidad mediante su capa middleware, la cualsoporta la redistribucion y la migracion de la interfaz de usuario. En cambio, los marcosPI, PEC, ACCDP, RCCG y GC solo mencionan la adaptacion de la interfaz de usuario acambios contextuales cuando sea necesario, pero no indican si esta adaptacion se hace medianteremodelacion, redistribucion o migracion.

La granularidad de la interfaz de usuario senala el grado en el que la interfaz deusuario ha sido modificada 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 ejemplifica a nivel de tarea. Aun cuando el marco PEC no especıfica laimplementacion de dicha granularidad, considera almacenar informacion de cada miembro. Elresto de los marcos, CAMELEON-RT, PI, ACCDP, RCCG y GC, no proporcionan indicios desoportar la granularidad del estado de recuperacion.

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 implementanun despliegue dinamico; el primero lleva a cabo dicho despliegue mediante sus modelos ob-servadores que se encargan de describir la realidad, la cual puede ser usada para llevar a cabola adaptacion; 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 clasifi-carse en: intra-espacio, inter-espacios y multi-espacios. La mayorıa de los marcos conceptuales(RUIUM-O, CAMELEON-RT, PI, PEC, ACCDP, RCCG y GC) no ofrecen suposicion algunade permitir la implementacion del espacio tecnologico; el marco RUIUM-O considera elcambio de codigo ejecutable cuando este no sea soportado por el nuevo contexto, solo que noindica si cambia o permanece en el mismo espacio tecnologico.

La Meta-interfaz de usuario (Meta-IU) muestra al usuario el proceso de plasticidad ycomprende las siguientes categorıas: con negociacion, sin negociacion, plastica e inexistente. Enel caso del marco RUIUM-O, este considera la Meta-IU con negociacion, ya que el desarro-llador puede intervenir en la adaptacion de cualquiera de las interfaces de usuario (abstracta,concreta y final) generadas por el marco. Mientras que el marco CAMELEON-RT toma encuenta la Meta-IU con negociacion en la capa de sistemas interactivos, ya que los usuariospueden manipular el espacio interactivo. Por otro lado, el marco PEC contempla el modelode dialogo para establecer el estilo de navegacion; dicho modelo puede considerarse como unaMeta-IU con dialogo. Finalmente, los marcos PI, PEC, ACCDP, RCCG y GC no proporcio-nan suficiente informacion para 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, tipo de contexto y variables contextuales.

El tipo de adaptacion esta conformado por la presentacion de informacion, la ejecucionautomatica de un servicio y la informacion aumentada. Los marcos RUIUM-O, PI, PEC,RCCG y GC no especifican que tipo de adaptacion llevan a acabo, ya que esta tarea quedaa cargo del desarrollador. En cambio, el marco CAMELEON-RT lleva a cabo un tipo deadaptacion catalogada como ejecucion automatica al llevar a cabo la redistribucion o migracion

Capıtulo 3 71

Marco con-ceptual

Tipo deadaptacion

Tipo de contextoVariables con-textuales

RUIUM-O no especifica mono-entidad contexto

CAMELEON-RT

ejecucion mono-entidad plataforma

PI no especifica multi-entidad 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 contexto

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

de la interfaz de usuario. El marco ACCDP proporciona ejemplos de adaptaciones, los cualescubren dos tipos de adaptacion, la primera corresponde a la presentacion de informacion cuandose siguiere mostrar informacion relevante a un grupo; la segunda se refiere a la informacionaumentada al mostrar informacion de interes en un lugar especıfico.

El tipo de contexto se refiere a considerar una sola entidad, mono-entidad, o a consid-erar varias entidades de forma simultanea, multi-entidad. Aun cuando los marcos RUIUM-Oy CAMELEON-RT consideran multiples variables contextuales, e.g., plataforma, entorno ytareas, dichos marcos son mono-entidad, ya que se centran en satisfacer un solo usuario. Losmarcos restantes pertenecen a la clasificacion multi-entidad, ya que los marcos PI y CG tienencomo objetivo mostrar la conciencia de grupo, mientras que el marco GC pretende proveerconciencia de contexto individual y grupal. Por su parte, el marco ACCDP es multi-entidadporque considera tanto las reacciones como las sugerencias de los usuarios presentes en un lugarpara proveer algun tipo de adaptacion. Finalmente, el marco RCCG implementan un contextoa nivel multi-objetivo, ya que considera los estados individuales de los usuarios para despuesgenerar un estado grupal.


Las variables contextuales son las 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, elmarco CAMELEON-RT tiene como variable contextual a la plataforma, pues a partir de ladeteccion de una plataforma la interfaz de usuario puede migrar o redistribuirse. En cambio,el marco PEC realiza la adaptacion de dos manera; la primera ocurre al genera la IU inicial yla segunda adaptacion ocurre cuando el cliente solicita la adaptacion. El marco ACCDP llevaa cabo la adaptacion cuando ocurre un cambio en algunas de las huellas digitales siguientes:presencia, enriquecimiento de la presencia, sugerencia de contenido y deteccion de reaccion.Por ultimo, el marco RCCG tiene como variables contextuales la actualizacion del estado deun usuario o la solicitud del estado global.

3.9 Sıntesis

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 unatendencia en considerar varias peculiaridades del usuario, e.g., el perfil y las preferencias, conla finalidad de proveer una mejor adaptacion de la interfaz de usuario. Estas caracterısticascontemplan ciertas acciones en especıfico, e.g., detectar las preferencias respecto a un tema.Por otro lado, la adaptacion a la plataforma se centra en acoplarse a las caracterısticas queofrece cada dispositivo de computo, pero la tendencia en este aspecto es utiliza sensores parapermitir la conciencia del entorno fısico, ademas de crear clusters de manera dinamica conlos dispositivos al alcance de los usuarios. En cuanto la adaptacion al entorno, los marcosestan tendiendo a modelar el entorno fısico, e.g., detectar a las personas en un lugar, ası comoproporcionar 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-interfaz de usuario, ası como llevar a cabo la adaptacion del sistema en tiempo deejecucion, dejando de lado las dimensiones.

Capıtulo 4

Analisis de requerimientos del marcoXARE

En este capıtulo se presenta una recapitulacion 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 co-laboradores, conjunto de plataformas y entorno comun, los cuales seran mencionados en variosescenarios que involucran procesos adaptativos. Dichas adaptaciones no han sido consideradasen el estado del arte analizado en los capıtulos 2 y 3. Para dar una idea mas clara de losrequerimientos evidenciados por estos procesos adaptativos, se proponen varias aplicaciones,algunas de las cuales son reutilizadas en varios de dichos escenarios (cf. Seccion 4.2).

Cada escenario esta estructurado en dos partes: 1) un preambulo y 2) una descripcion de-tallada. La primera parte explica brevemente las posibles adaptaciones contextuales de lasaplicaciones encargadas de automatizar parcial o completamente algun proceso de trabajo co-laborativo, mientras que la segunda parte ejemplifica el ambito del escenario y pone en evidencialos diferentes contextos de uso de las aplicaciones colaborativas involucradas, las cuales fuerongeneradas a partir de un conjunto de requerimientos funcionales y no funcionales (cf. Seccion4.3-4.9).

Finalmente, se presentan una sıntesis derivada de este capıtulo (cf. Seccion 6.3).

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 InteraccionHumano-Computadora (IHM), tales como la capacidad de los sistemas interactivos para ejecu-tarse en diferentes contextos de uso. Probablemente la definicion de contexto mas referenciada

73

74 Analisis de requerimientos del marco XARE

es la que proponen Dey et. al, la cual dice [Dey et al., 2001]:

“Contexto es cualquier informacion que puede ser usada para caracterizar lasituacion de una entidad. Una entidad es un usuario, un lugar, un objeto fısicoo de computo que es considerado relevante para la interaccion entre un usuario yuna aplicacion, incluyendo al propio usuario y a dicha aplicacion.”

4.1.1 Contexto de uso de los sistemas mono-usuario

Como se menciono en el capıtulo 1, la plasticidad de interfaces de usuario en el dominio de lossistemas mono-usuario [Calvary et al., 2006] se define como:

“La capacidad de las interfaces de usuario de adaptarse a cambios en el contextode uso, preservando un conjunto de criterios de calidad, como la usabilidad y lacontinuidad de interaccion”.

Por contexto de uso se entiende la terna <usuario, plataforma, entorno> donde el compo-nente usuario denota el arquetipo humano que tiene por objeto utilizar el sistema interactivo[Vanderdonckt, et al., 2008]. Este componente comprende varios elementos: perfil, actividad[Coutaz and Calvary, 2008] y rol, los cuales actuan como factores externos al sistema que de-pende del usuario y que pueden llegar a modificar el conjunto de funcionalidades que ofrece elsistema.

En el ambito de los sistemas mono-usuario, los factores anteriores (perfiles, actividades yroles) han sido analizados en conjunto. Algunos estudios se han limitado a adaptar las fun-cionalidades de un sistema a diferentes perfiles de usuario. La adaptacion se lleva a cabo demanera personalizada, ya que las necesidades y preferencias del usuario solo afectan a la in-stancia del sistema que el esta ocupando, sin afectar a las instancias de los demas usuarios.Algunos ejemplos de este tipo de adaptacion serıan informar a los usuarios de una librerıa sobrela llegada de nuevo material, segun el perfil de cada uno de ellos [Amato and Straccia, 1999],o permitir a los usuarios decidir la manera en que desean ser contactados, dada una situaciondeterminada [Stan et al., 2008].

El componente 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 los mediosde interaccion motivan la seleccion de un conjunto de modalidades de E/S y la cantidad deinformacion disponible [Calvary et al., 2001, Calvary et al., 2004].

El componente 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 se

Capıtulo 4 75

esta 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., 2001, Calvary et al., 2004].

4.1.2 Contexto de uso de los sistemas colaborativos

El desarrollo de un espacio de interaccion colaborativo puede resultar complejo, ya que sedeben considerar varios aspectos, e.g., las actividades de los colaboradores y la conciencia degrupo. Dourish y Bellotti definen la conciencia de grupo como un conocimiento de las activi-dades de otros que provee un contexto para las actividades propias. Algunos investigadoresconsideran que la conciencia puede clasificarse en cuatro tipos [Dourish and Bellotti, 1992,Gutwin et al., 1995]:

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

• conciencia de grupo estructural: proporciona informacion de roles, responsabilidades,posicion social o profesional de los miembros de un grupo;

• conciencia social: permite el entendimiento del contexto tanto social como conversacionalde los colaboradores, y

• conciencia de espacio del trabajo: ofrece informacion sobre la interaccion de los miembrosde un grupo en el espacio de trabajo 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, entornocomun> para denotar el contexto de uso de los sistemas colaborativos. 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 alguna actividad.

El componente grupo de colaboradores denota los arquetipos humanos que utilizan elsistema colaborativo para llevar a cabo un proyecto comun.

El componente conjunto de plataformas se refiere a las caracterısticas de hardware ysoftware de los dispositivos de computo que alojan al sistema colaborativo y que son usadosde manera individual por cada colaborador (e.g., una computadora portatil o un telefono in-teligente) o de forma compartida por algunos miembros del grupo (e.g., un pizarron interactivo).Este componente tambien incluye los dispositivos que permiten un mejor funcionamiento delsistema colaborativo (e.g., impresoras y servidores).


El componente entorno comun se refiere a las condiciones fısicas y sociales, e.g., personas,objetos y eventos, que son externos al grupo de trabajo, pero que tienen una influencia tantoen los miembros del grupo como en el sistema colaborativo. Este componente tambien incluyeun entorno virtual, e.g., un desktop, los espacios de trabajo publicos y privados de aplicacionescolaborativas y objetos compartidos. Un desktop se define como un conjunto de aplicacionesdisponibles para un colaborador dependiendo su rol [Haake et al., 2010]. Los objetos compar-tidos se refieren al texto, a las imagenes, al audio y al video que son compartidos por loscolaboradores a traves del espacio de trabajo publico de una aplicacion colaborativa.

4.2 Relacion entre escenarios y aplicaciones

La tecnica usada para crear el marco XARE es la de bottom-up. Por consiguiente, se partiode un conjunto de escenarios que nos sirvieron para identificar los requerimientos de algunasaplicaciones colaborativas adaptables a cambios contextuales. A partir de estos requerimientos,se crearon los diagramas de clase del marco XARE, los cuales seran presentadas en el capıtulo5.

Los cambios contextuales abordados en esta tesis se ponen en evidencia en siete escenariospropuestos (cf. Figura 4.1). Algunos de ellos hacen referencia a aplicaciones computacionales,cuyo objetivo es facilitar la colaboracion entre los miembros de un grupo. En la figura 4.1, losrectangulos que representan a los escenarios muestran diferentes colores (verde oliva, amarilloy rosa) con el fin de denotar el grado de aportacion al diseno del marco XARE. El color verdeoliva indica que se detectaron suficientes aplicaciones para automatizar el proceso colaborativodescrito en el escenario; el color amarillo indica que las aplicaciones identificadas no aseguranuna automatizacion completa y finalmente, el color rosa significa que hasta el momento no sehan identificado aplicaciones especıficas.

Asimismo en la Figura 4.1, las aplicaciones tambien han sido representadas con diferentescolores (azul, naranja y rojo) para denotar su estado de avance. El color azul representa a lasaplicaciones implementadas; el color verde denota a las aplicaciones en proceso de desarrollo ypor ultimo el color rojo representa a las aplicaciones que no han sido implementadas.

Para lograr un mejor entendimiento de la Figura 4.1, primero se describen brevemente lasaplicaciones identificadas:

1. la barra de colaboradores [Romero et al., 2013] expresa la conciencia de grupo mediantela foto y el nombre de los colaboradores pertenecientes a un equipo de trabajo. Dichabarra organiza a los colaboradores, dependiendo su ubicacion fısica, como: presentes,virtualmente presentes y 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;

Capıtulo 4 77

Escenario 6:

Suministro de

información relevante

Escenario 3:

Redistribución

de una aplicación

colaborativa

Escenario 4:

Mejoramiento de la

conciencia grupal

Escenario 1:

Mejoramiento del

trabajo colaborativo

Escenario 7:

Notificaciones multi-

modales

Escenario 5: Manejo

de intromisiones

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 con suficientes aplicaciones para auto-

matizar un proceso colaborativoEscenario carente de aplicaciones

Escenario con aplicaciones para auto-

matizar un proceso colaborativo

insuficientes

Aplicación en proceso de desarrollo

Escenario 2:

Remodelación de la

interfaz de usuario

Figura 4.1: Relacion entre escenarios y aplicaciones colaborativas

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

4. el editor de dibujos tiene como objetivo permitir la creacion de imagenes vectoriales ytiene la caracterıstica de soportar transiciones del trabajo individual al trabajo colabo-rativo y viceversa. Los colaboradores pueden pasar de su respectivo espacio privado aun espacio comun donde pueden interactuar mediante un dispositivo con una pantallagrande (e.g., un pizarron interactivo) o un arreglo de tablets. Estas transiciones originanque las funcionalidades de la aplicacion se adapten para dar soporte a la interaccion demultiples usuarios, considerando sus roles y sus jerarquıas;

5. la herramienta de medios de contacto y disponibilidad [Decouchant, et al., 2013] presentade manera visual tanto la disponibilidad como los medios de contacto accesibles de un


colaborador, considerando varios parametros, tanto del colaborador a contactar como delque desea contactarlo;

6. la desktop enriquecido [Decouchant, et al., 2013] permite relacionar objetos manipuladosentre diferentes aplicaciones mediante referencias deıcticas, las cuales son capaces demantener, en todo momento, el contexto de dichos objetos, con el fin de mejorar eltrabajo de los colaboradores que los comparten;

7. el administrador de contenidos vıa NFC [Romero et al., 2013] enriquece las reunionesco-localizadas al proveer a los colaboradores informacion relevante en el tiempo y lugarindicado, mediante la tecnologıa NFC (Near Field Communication);

8. el editor de textos permite ocultar informacion restringida ante personas no autorizadasque estan cerca del area de despliegue de dicha informacion.

Es importante mencionar que la herramienta de votacion y el editor de mapas mentales per-miten tanto la interaccion co-localizada como la distribuida. Ambas aplicaciones muestran lasfuncionalidades relacionadas al rol de cada colaborador en su respectiva instancia. Finalmente,ambas aplicaciones usan la barra de colaboradores para proveer conciencia de grupo.

Despues de haber descrito brevemente las aplicaciones identificadas durante la fase de analisis,a continuacion se describen los escenarios representados en la Figura 4.1:

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 ob-jetos compartidos en el espacio de trabajo y al encontrar algunas relaciones entre loscolaboradores, en funcion de su interaccion con dichos objetos. A partir de las relacionesencontradas, se hacen sugerencias pro-activas, tales como poner a disposicion de los co-laboradores aplicaciones adecuadas para manipular un objeto dado, dependiendo de surol, o asociar diferentes conversaciones textuales en curso que hacen referencia a dichoobjeto. La herramienta relacionada con este escenario es la de desktop enriquecido.

2. El escenario “Remodelacion de la interfaz de usuario” permite la modificacion de compo-nentes mediante las siguientes acciones: ocultar, sustituir o agregar; en particular, lamodificacion incluye referenciar a otro dispositivo de hardware que proporcione la mismafuncionalidad del componente modificado. Este escenario es importante, ya que sus espe-cializaciones se representan en los escenarios del tres al seis. Aun cuando existen particu-laridades en estos escenarios es importante recalcar que este segundo escenario permiteadaptar los ıconos (e.g., en la herramienta de mapas mentales los iconos relacionados conel rol de autor son mostrados, solo para los colaboradores que tienen asignado dicho rol)y las aplicaciones (e.g., desktop enriquecido) en funcion del rol de los colaboradores y deltamano de la pantalla del dispositivo.

3. El escenario “Redistribucion de una aplicacion colaborativa” adapta los componentes queson afectados por el trabajo co-localizado y redistribuido. Algunos de los componentes

Capıtulo 4 79

detectados que son susceptibles de dichas modificaciones corresponden a los espacioscompartidos y publicos, a la conciencia de grupo y al uso de dispositivos con pantallasgrandes y de buena resolucion para una mejor interaccion (e.g., un pizarron interactivo).Las herramientas asociadas a este escenario corresponden a: herramienta de votacion,editor de mapas mentales, editor de dibujos y barra de colaboradores.

4. El escenario “Mejoramiento de la conciencia grupal” modifica los componentes relaciona-dos con la disponibilidad y los medios de contacto dependiendo de algunos parametrosrelacionados con los colaboradores. La herramienta relacionada con este escenario es lade medios de contacto y disponibilidad.

5. El escenario “Manejo de intromisiones” adapta la informacion desplegada en un disposi-tivo, e.g., pizarron interactivo o una computadora portatil, al detectar a una persona queno pertenece al equipo de trabajo. En este caso, la informacion es cambiada por otra demenos relevancia para que no pueda ser visualizada por dicha persona. En este escenario,se envıa una notificacion al resto del grupo de colaboradores acerca de la presencia dealguien ajeno al equipo para que no envıen mensajes u otro tipo de informacion impor-tante en ese momento. La herramienta relacionada a este escenario corresponde al editorde textos.

6. El escenario “Suministro de informacion relevante” permite proveer informacion que puedeser util a los colaboradores, considerando el lugar, la fecha y el rol de estos. Este escenariotiene asociada la herramienta administrador de contenidos vıa NFC.

7. El escenario “Notificaciones multi-modales” ofrece una gama de posibilidades para noti-ficar a los colaboradores acerca de un evento en especıfico, considerando la actividad encurso de cada uno de ellos, ası como la importancia de dicho evento. Este escenario hastaal momento no tiene asociada una aplicacion.

4.3 Escenario 1: Mejoramiento del trabajo colaborativo

Este escenario describe un entorno virtual cuya finalidad es mejorar la colaboracion entre losmiembros de un grupo. Para lograr este fin, dicho entorno ofrece aplicaciones colaborativasadecuadas, dependiendo del rol de cada colaborador, y permite asociar objetos de diferentesaplicaciones mediante referencias deıcticas, las cuales mantienen en todo momento el contextode dichos objetos.

Antes de describir el escenario, se presenta una introduccion acerca de las aplicaciones co-laborativas adaptativas que han sido identificadas en este escenario, ası como de los roles y lagranularidad de los objetos compartidos soportados por estas aplicaciones.


4.3.1 Preambulo

Para relacionar y mantener el contexto de los objetos producidos durante una sesion de tra-bajo, un grupo de colaboradores utiliza un desktop enriquecido que provee varias aplicacionescolaborativas disenadas para trabajar en conjunto.

Una instancia del desktop enriquecido es ejecutada automaticamente al momento de quecada uno de los colaboradores ingresa a la sesion para trabajar en las tareas asignadas. Eneste caso de estudio, el desktop enriquecido ofrece tres aplicaciones, cuyos objetivos puedenestar relacionados entre sı mediante referencias deıcticas para enriquecer la interaccion. Lasaplicaciones son las siguientes:

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

2. Un editor colaborativo que permite la fragmentacion de documentos HTML para facilitarla produccion concurrente. Una imagen que esta siendo desplegada por este editor puedeser arrastrada hacia el pizarron multi-usuario donde puede ser modificada. De esta man-era, no hay necesidad de realizar las tradicionales operaciones de copiar/pegar o abrirarchivo para acceder a dicha imagen desde el pizarron multi-usuario. Ademas, la actual-izacion de la imagen desplegada por el editor colaborativo se hace de manera automatica,ya que este mantiene un identificador de dicha imagen mientras esta permanece abiertaen el pizarron multi-usuario.

3. Un servicio de mensajerıa que soporta la comunicacion directa entre los miembros deun grupo y que es capaz de relacionar diferentes conversaciones que hacen referenciasdeıcticas a un mismo objeto compartido que esta siendo manipulado mediante el editorcolaborativo o el pizarron multi-usuario.

La granularidad de los objetos compartidos soportada por el editor colaborativo va desdeuna palabra, una frase, un parrafo o una seccion hasta todo el documento. De manera simi-lar, el pizarron multi-usuario permite la manipulacion de diferentes granularidades, las cualesvan desde figuras basicas (e.g., lıneas, cuadrados, cırculos y rectangulos) hasta un diagramacompleto.

La tercera aplicacion soporta grupos no estratificados, mientras las dos primeras soportantres roles:

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

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

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

Capıtulo 4 81

Es importante mencionar que no todas las aplicaciones colaborativas adaptativas contenidasen el desktop enriquecido estan visibles en todo momento para evitar que el usuario se saturecon aplicaciones que no son de utilidad para la actividad en curso. Con el objetivo de proveera los colaboradores con un entorno colaborativo apropiado, las herramientas estan disponiblesdependiendo del rol actual del colaborador. De este modo, un colaborador con el rol de escritor,podrıa requerir ejecutar en su desktop enriquecido tanto el editor colaborativo como el pizarronmulti-usuario. En el caso de un colaborador con el rol de revisor, este podrıa necesitar que lamensajerıa instantanea trabaje de manera coordinada con el editor colaborativo y el pizarronmulti-usuario para hacer comentarios acerca del texto o de los diagramas del documento.

4.3.2 Descripcion del escenario

Suponga que un grupo compuesto por cuatro miembros, Alice, Isaac, Jenny y Sandy, estapreparando un reporte tecnico de manera distribuida. Aunque los miembros del grupo utilizandispositivos heterogeneos, estos tienen caracterısticas tecnicas suficientes (e.g., buen tamanoy alta definicion de pantalla, ası como alto poder de procesamiento y capacidades de comu-nicacion). Dadas las caracterısticas de los dispositivos, la adaptabilidad de las aplicacionescolaborativas no se expresa mediante la remodelacion de su interfaz de usuario, sino por lasfuncionalidades que dichas aplicaciones proveen para que los miembros del grupo puedan llevara cabo sus actividades.

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 revisarla. 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 que larevisen conjuntamente dicha seccion, ya que ella tiene algunos problemas para expresar susideas. En consecuencia, estos colaboradores deciden entablar una comunicacion directa medi-ante la mensajerıa instantanea, mientras que el editor colaborativo esta a cargo de mostrarleslos parrafos sujetos a revision.

El desktop enriquecido provee una funcionalidad de deixis, la cual permite a los colab-oradores crear referencias deıcticas, en forma de ligas de hipertexto, entre objetos de la her-ramienta de la mensajerıa instantanea (e.g., palabras deıcticas como this figure, the next section,this paragraph, those references o here) y objetos del editor colaborativo (e.g., un tıtulo, unparrafo, una frase, una palabra, una referencia bibliografica, una figura o una seccion). Graciasa esta funcionalidad, los colaboradores no necesitan copiar los objetos referenciados desde eleditor colaborativo hacia la mensajerıa instantanea cuando estan revisando. De este modo,los objetos referenciados siempre mantienen su contexto en el editor colaborativo, i.e., parrafosanteriores y siguientes, figuras asociadas y referencias bibliograficas.


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 mensajerıa instantanea para referirse a un parrafo mostrado enel editor colaborativo

Mediante la funcionalidad deixis, Isaac escribe en la mensajerıa instantanea: “. . . inthis paragraph, you are using the concept “view-controller pair” without defining it . . . ”. Comopuede observarse en la Figura 4.2, las palabras deıcticas “this paragraph” de la frase previatienen una liga de hipertexto que apunta a un parrafo del documento abierto en el editor co-laborativo. Cuando Sandy da clic en la liga creada por Isaac, el editor colaborativo muestra elparrafo correspondiente a la mitad de la vista y lo resalta con letra de color roja, en este caso.

Como el parrafo en cuestion mantiene su contexto, i.e., referencias bibliograficas, parrafoscircundantes y figuras referenciadas, Sandy puede darse cuenta que el comentario de Isaac escorrecto, ya que ella pueda facilmente verificar que el concepto “view-controller pair” no estadefinido en parrafos previos de la seccion.

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 que hancreado. Como se ilustra en la Figura 4.3, la mensajerıa instantanea muestra que Alice escribio

Capıtulo 4 83

“. . . I’d like to highlight H1 in this diagram”. Al igual que Isaac, Alice creo una referenciadeıctica a la figura 1 del reporte tecnico. De este modo, cuando Jenny da clic en las palabrasdeıcticas “in this diagram”, el editor colaborativo muestra el diagrama correspondiente a la mi-tad de la vista resaltandolo mediante un borde color azul. Este diagrama referenciado tambienmantiene su contexto, i.e., seccion contenedora, tıtulo de la figura y parrafos circundantes.

Hi Jenny! I’d like to highlight H1 in

this diagram as it’s the key node…

Hello Alice! I agree with you, so

shoulders to the wheel!

Jenny

Alice






















Figura 4.3: Uso de las palabras deıcticas “in this diagram” (en la forma de una liga de hiper-texto) por parte de Alice en la mensajerıa instantanea para referirse a una figura mostrada enel editor colaborativo

Como no es posible modificar este diagrama desde el editor colaborativo, el desktop enrique-cido provee una funcionalidad que permite a los colaboradores hacer una replica de tal diagramaen el pizarron multi-usuario, donde este puede ser modificado. Esta replica mantiene una refer-encia contextual al diagrama mostrado en el editor colaborativo (en este caso, un identificadorde objeto interno y la localizacion del objeto en el documento). Por lo tanto, gracias a estareferencia contextual, el desktop enriquecido permite a los colaboradores reemplazar la versioncaducada del diagrama mostrado en el editor colaborativo, por la nueva version creada en elpizarron multi-usuario.


Como Alice y Jenny decidieron modificar tal diagrama, una replica es automaticamentecreada en el pizarron multi-usuario. En ese momento, el desktop enriquecido deduce que Sandye Isaac estan escribiendo un parrafo que hace referencia a la figura que esta siendo modificadapor Alice y Jenny. En consecuencia, el desktop enriquecido sugiere a Sandy e Isaac seguir laconversacion de Alice y Jenny porque puede ser de interes, ya que ellas estan modificando lafigura asociada al parrafo que ellos estan redactando. Esta sugerencia tambien es hecha a Alicey Jenny. En caso de que Sandy e Isaac esten interesados en seguir la conversacion de Alice yJenny (cf. Figura 4.4) y viceversa (cf. Figura 4.5), ellos pueden acceder a estas conversacionespor medio de una nueva pestana agregada en sus respectivos mensajeros instantaneos.

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

El desktop enriquecido pretende hacer mas eficiente el trabajo grupal, adaptandose a lasactividades de los colaboradores. Gracias a estas funcionalidades adaptativas, los cuatro colab-oradores pueden coordinar facilmente su trabajo al evitar errores, duplicaciones innecesarias ymalos entendidos. Si es necesario, estos colaboradores pueden comunicarse directamente paracoordinar sus respectivos trabajos, sin perder el contexto de los objetos creados conjuntamente.

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

Adaptacion al contexto de uso de los sistemas colaborativos

En este escenario, la adaptacion al contexto de uso se aborda de dos maneras. La primerapermite la adaptacion al grupo de colaboradores, ya que el desktop enriquecido considera elrol del colaborador para ofrecer solo las aplicaciones relevantes para ese rol. La segunda formade adaptacion considera al entorno compartido ya que, por un lado, el desktop enriquecidopermite relacionar objetos de diferentes aplicaciones mediante referencias deıcticas. Por otrolado, la mensajerıa instantanea es capaz de detectar diferentes conversaciones en curso quehacen referencia a un mismo objeto compartido, con el fin de hacer sugerencias pro-activas alos colaboradores, e.g., seguir la conversacion de sus colegas para conocer sus intenciones decambios respecto a un objeto compartido dado.


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 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 o a objetos relacionados.

Requerimientos funcionales y no funcionales

Los requerimientos funcionales del desktop enriquecido se listan a continuacion:

• Autentificar a cada colaborador al ingresar a una sesion.

• Adaptar la interfaz de usuario dependiendo cada colaborador, i.e., mostrar los ıconos deacceso rapido a las aplicaciones relacionadas con el rol asignado.

• Permitir que los colaboradores puedan usar la funcion Deixis a partir de la mensajerıainstantanea para crear referencias deıcticas que referencien diferentes objetos compar-tidos, los cuales pueden ser parrafos, palabras o imagenes, que sean desplegados por eleditor colaborativo. La creacion de referencias deıcticas requieren los siguientes pasos:1) seleccionar el ıcono de deixis para desplegar la ventana llamada “New Deixis”; 2)seleccionar las palabras que serviran de referencia deıctica, e.g., this paragraph, dentro dela ventana abierta, 3) seleccionar en el editor colaborativo el objeto compartido al que sehara referencia y 4) aceptar para terminar de crear la nueva deixis.

• Permitir el acceso a la referencia deıctica al seleccionar con el cursor la palabra deıctica.En consecuencia, el desktop enriquecido podra mostrar la referencia al objeto. En casode que el objeto referenciado sea un parrafo, este cambiara el color de la letra a rojo paraindicar que se esta haciendo referencia a ese parrafo. En caso de que el objeto referenciea una imagen, esta estara enmarcada con un recuadro de color azul.

• Crear una replica de la imagen referenciada del editor colaborativo en el pizarron multi-usuario para hacer modificaciones sobre dicha imagen. Una vez terminadas las modi-ficaciones, el objeto sera actualizado automaticamente en el documento, donde ha sidoreferenciado.

• Sugerir seguir una conversacion al detectar que dos conversaciones hacen referencia a unobjeto compartido o a objetos relacionados.

Los requerimientos no funcionales del desktop enriquecido corresponden a:

Capıtulo 4 87

1. Mostrar en medio de la vista del editor colaborativo el objeto compartido al que se estahaciendo referencia.

2. Permitir la creacion de varias referencias deıcticas en una conversacion, ası como mantenerlas ligas a dichos objetos en forma de hipertexto.

3. Mostrar las palabras deıcticas, e.g., in this paragraph, en la mensajerıa instantanea encolor azul y subrayada.

4. Abrir el pizarron multi-usuario cuando los colaboradores deseen crear una replica de unaimagen referenciada, la cual posteriormente sera modificada y actualizada.

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) sugiere alos colaboradores seguir las conversaciones publicas de sus colegas que estan relacionadas conel trabajo en desarrollo (cf. Figura 4.4 y 4.5).

Las variables que son consideradas para la adaptacion contextual corresponden a: 1) rol delcolaborador, 2) referencia deıctica, 3) objetos compartidos en uso y 4) conversaciones actuales.

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

La variable de referencia deıctica contiene las figuras o el texto al que se hace referencia sinque estos pierdan su contexto.

La variable de objetos compartidos en uso almacena los objetos en uso de todos los colabo-radores que interactuan en un momento dado. Dicha variable permite identificar el grado derelacion entre dichos objetos compartidos para proveer sugerencias pro-activas.

La variable de conversaciones actuales registrara las conversaciones de los colaboradores enun momento dado. Esta variable permitira que dichas conversaciones sean visualizadas porotros colaboradores como resultado de una 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. Despues de que el desktopenriquecido autentifica al colaborador solicita a una base de datos los roles de dicho


usuario, para determinar las aplicaciones relacionadas con los roles obtenidos, con lafinalidad de ponerlas accesibles al colaborador, e.g., un revisor requiere acceder al editorcolaborativo, a la mensajerıa instantanea y posiblemente al pizarron multi-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 una 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 convierte la palabra seleccionada en una hiperliga con estilo bold y colorazul marino (cf. Figura 4.3).

3. Un colaborador selecciona una referencia deıctica desde la herramienta demensajerı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 circundada 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 texto.

4. El colaborador selecciona la opcion ”Make a copy”. Esta opcion es activada despuesde que una figura fue seleccionada desde el editor colaborativo. 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 eventode actualizar una copia es generado por un colaborador que solicito dicha copia, desde eleditor colaborativo. Al momento de solicitar dicha actualizacion, el pizarron multi-usuarioremplaza la figura del editor colaborativo por la figura que tiene el pizarron.

6. El desktop enriquecido propone seguir una conversacion. Este evento sucedecuando el desktop enriquecido detecta que varios colaboradores hacen referencia a un ob-jeto compartido o bien a objetos relacionados. En consecuencia, mediante una ventana, eldesktop enriquecido, propone a los colaboradores en cuestion seguir la conversacion actualque llevan a cabo sus colegas por mensajerıa instantanea para facilitar su trabajo, ya quetodos estos colaboradores hacen referencia al mismo objeto o a objetos relacionados.

Capıtulo 4 89

7. Los colaboradores aceptan 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 otros colaboradores (cf. Figura 4.2).

4.4 Escenario 2: Remodelacion de la interfaz de usuario

El objetivo de esta propuesta es ocultar, sustituir o agregar componentes de los sistemas colab-orativos. 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ıa delas veces los usuarios no utilizan algunos de estos componentes por muchas razones. Algunosmotivos para ocultar o sustituir los componentes o funcionalidades se mencionan a continuacion:

• mostrar solo los iconos relacionados con la actividad en curso, e.g., si un revisor de unartıculo ingresa al editor colaborativo, esta aplicacion debe ocultar los ıconos no rela-cionados a sus actividades, e.g., el ıcono de insertar imagen;

• ocultar componentes cuando:

– se detecte que algunos de los ıconos relacionados con el rol no sean utilizados por elcolaborador que este usando la instancia de una aplicacion;

– estos no tengan funcionalidad debido a que el recurso humano o fısico asociado noesta disponible, e.g., el ıcono de una impresora debe ocultarse cuando esta descom-puesta o el avatar de un colaborador fuera de lınea puede ser agregado a una listade colaboradores ausentes;

• 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 ejemplifica el presente escenario es un editor de mapas mentales quepermite que los colaboradores puedan asumir los siguientes roles:

• administrador, el cual permite crear un nuevo mapa mental, elegir a los participantes yasignarles un rol;

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

• revisor, el cual 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 del dispositivo en uso. Dichas dimensiones son clasificadasen: 1) pantalla pequena, cuando la pantalla del dispositivo es de un tamano menor a sietepulgadas y 2) pantalla grande, cuando la pantalla del dispositivo es de siete pulgadas o mas.


Supongamos que un grupo de colaboradores, compuesto por Coello, Mejia, Fraga,Chakraboborty y Morales, necesita realizar un mapa mental sobre software libre. Dichos co-laboradores planearon formalmente una cita que fue registrada en la agenda de la sala dereuniones.

Coello y Fraga asisten a la reunion llevando consigo cada uno un telefono inteligente, mientrasque Morales acude con su tablet PC. Cuando Coello, Fraga y Morales entran a la sala dereuniones son autenticados automaticamente por medio de una etiqueta NFC que se encuentraen la entrada de la sala. Mientras tanto, Mejia y Chakraborty entran al sistema manualmenteintroduciendo su nombre de usuario y contrasena mediante su tablet PC, ya que ellos handecidido interactuar con sus colegas de manera remota.

Cuando Coello 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 (cf. Figura 4.6). Ademas, se visu-aliza una barra de colaboradores donde se muestran los colaboradores virtualmente presentes,en este caso el nombre y la foto de Mejia y Chakraborty. Desde la pantalla principal, Coelloejecuta el editor colaborativo de mapas mentales, el cual le asigna el rol de administrador

que le permitira seleccionar a los coautores y asignarles sus respectivos roles. Coello decide

Capıtulo 4 91

dar el rol de revisor a Mejia y Chakraborty, en tanto el rol de autor es asignado a Coello,Fraga y Morales (cf. Figura 4.7). En particular, el rol de autor permite la adicion, eliminaciony modificacion de los elementos del mapa mental, mientras que el rol de revisor permite laadicion, modificacion y eliminacion de comentarios asociados a dichos elementos. Una vez queCoello concluyo la asignacion de roles a los coautores, el editor de mapas mentales se ejecutaautomaticamente en los dispositivos moviles de sus colegas.

Figura 4.6: Pantalla principal donde se muestran las aplicaciones disponibles y una barra decolaboradores que exhibe a los miembros ausentes y virtualmente presentes

La interfaz de usuario del editor de mapas mentales se adapta a las dimensiones de la pantalladel dispositivo, a la configuracion del grupo y al rol del usuario (administrador, autor yrevisor). Por lo tanto, la interfaz de usuario desplegada en el pizarron interactivo muestra adetalle el mapa metal ası como las funcionalidades relacionadas con el rol de revisor y autor

(cf. Figuras 4.8 y 4.9 respectivamente).

Por otro lado, la interfaz de usuario de Morales muestra una vista detallada del mapa mental(cf. Figura 4.10a). En tanto que la interfaz de usuario que puede visualizar Mejia muestra unavista detallada del mapa mental, ası como un barra de colaboradores que contiene el nombre yla foto de los participantes virtual y fısicamente presentes (cf. Figura 4.10b). Por el contrario,


Figura 4.7: Pantalla para elegir a los participantes en la creacion del mapa mental y sus roles

en el dispositivos de Fraga, la interfaz de usuario de esta herramienta muestra una vista radarinteractiva [Utwin et al., 1996] donde se presenta unicamente la estructura del mapa mental(cf. Figura 4.10c).

A traves de la vista radar interactiva mostrada en el dispositivo movil de Fraga puede anadir,modificar, mover y eliminar elementos, mientras observan una vista detallada del mapa mentalen el pizarron interactivo. Mejia puede agregar, modificar y eliminar comentarios desde la vistadetallada del mapa mental mostrada en su tablet, i.e., el editor de mapas metales ofrece sololas funcionalidades autorizadas al rol del colaborador.

Despues de que Fraga trabaja un largo rato en el mapa mental, el decide guardar su trabajoen su telefono inteligente. Entonces Fraga selecciona el ıcono de guardar, el cual despliega unletrero indicando que su dispositivo no tiene suficiente espacio para almacenar el diagrama, asıque el editor de mapas mentales propone utilizar el disco duro de la tablet PC de Morales o elde un servidor. Es importante mencionar que el editor no ofrece el disco duro de Jenny porqueella esta fuera de lınea.


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

La adaptacion al grupo de colaboradores se logra ya que a partir del rol del colaborador, eleditor de mapas mentales decide ocultar los iconos no utilizados. En el caso de Mejia, el editorde mapas mentales solo ofrece las funcionalidades que le permiten manipular (agregar, modificar

Capıtulo 4 93

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

y eliminar) comentarios. Por otra parte, el sistema considera el conjunto de plataformasde dos maneras: 1) el mapa mental es mostrado mediante una vista radar interactiva o unadetallada dependiendo de las dimensiones de la pantalla del dispositivo en uso, y 2) la fun-cionalidad “guardar localmente” es sustituida por guardar en otro dispositivo, e.g., un servidoro el dispositivo que esta usando Morales.

4.4.3 Editor de mapas mentales

El editor de mapas mentales ofrece principalmente tres caracterısticas: 1) permite que el grupode colaboradores trabaje de manera co-localizada y distribuida, 2) adapta las funcionalidadesofrecidas dependiendo del rol del colaborador y 3) adapta la vista del mapa mental al tamanoy a la resolucion de la pantalla del dispositivo en uso.


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

1. Identificar al administrador del mapa mental.


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

2. Permitir que el administrador pueda crear un nuevo mapa mental, seleccionar a losparticipantes 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 y eliminar elementos o comentarios desde una vista detalladamostrada en un pizarron interactivo o una tableta.

5. Permitir agregar, modificar y 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.

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).

Capıtulo 4 95

(a) Vista detallada en la tablet de un autor

co-localizado(b) Vista detallada en la tablet de unrevisor distribuido

(c) Vista radar interactiva enel telefono de un autor co-localizado

Figura 4.10: Adaptabilidad de la interfaz de usuario del editor colaborativo de mapas mentalescon base en la configuracion del grupo, las dimensiones de la pantalla y el rol del usuario


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.

5. Permitir exportar el mapa mental a una imagen en formato PNG.

Interfaz de usuario

Para llevar a cabo la adaptacion al contexto, la aplicacion editor de mapas mentales consideralas siguientes variables contextuales: 1) el rol del colaborador, 2) la configuracion del grupo y3) las dimensiones de la pantalla de despliegue.

Los roles que puede asumir un usuario son: 1) administrador, 2) autor y 3) revisor. Enel caso del administrador , la interfaz de usuario solo muestra las opciones necesarias paraasignar los roles y establecer el nombre del mapa mental (cf. Figura 4.7). En el caso del autor,la interfaz de usuario muestra las funcionalidades necesarias para agregar, modificar, mover oeliminar elementos (cf. Figura 4.9). Finalmente, la interfaz de usuario de un revisor ofrecelas mismas funcionalidades que para un autor, con la diferencia de que el autor manipulaelementos y el revisor manipula comentarios (cf. Figura 4.8).

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 la 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 (cf. Figura 4.10).


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 crea un nuevo mapa mental: la aplicacion envıa una notificaciona los dispositivos moviles de los participantes presentes y virtualmente presentes, dondese solicita su participacion.

2. Un colaborador selecciona la notificacion de participacion en la creacion deun mapa mental: se ejecuta el editor colaborativo de mapas mentales en su dispositivoy la interfaz de usuario de dicho editor se adapta de tal manera que despliega unicamentelas opciones disponibles para el rol del colaborador (autor o revisor). En las Figuras

Capıtulo 4 97

4.9 y 4.8 se muestra la interfaz de usuario del editor colaborativo de mapas mentalesdesplegada en el pizarron interactivo, cuando dos usuarios juegan los roles de revisor yautor.

De igual manera, la interfaz de usuario se adapta de acuerdo a la combinacion de las sigu-ientes variables contextuales: a) configuracion del grupo y b) dimensiones de la pantallade despliegue. Tanto para los colaboradores co-localizados como para los distribuidos queutilizan dispositivos con pantalla grande, la vista detallada muestra toda la informaciondel mapa mental, i.e., la etiqueta de cada nodo y la etiqueta de cada conexion entre unpar de nodos, si existen (cf. Figura 4.10a). Para los participantes distribuidos, se mues-tra adicionalmente una barra de los colaboradores fısicamente presentes en el lugar dereunion, virtualmente presentes y ausentes (cf. Figura 4.10b).

En la vista radar interactiva unicamente se puede observar la estructura del mapa mental,ya que las dimensiones de la pantalla del dispositivo no permiten una buena visibilidadde los detalles del mismo (cf. Figura 4.10c).

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 cambiosrealizados por un colaborador, ya sea autor o revisor, se ven reflejados en el pizarroninteractivo y en los dispositivos de todos sus colegas.

4. El mapa mental sobrepasa las dimensiones del pizarron interactivo: la vistadel mapa mental presentada en dicho pizarron muestra una barra de desplazamientohorizontal y una vertical.

4.5 Escenario 3: Redistribucion de una aplicacion colab-

orativa

Este escenario pretende ilustrar funcionalidades necesarias cuando los colaboradores estan tra-bajando co-localizadamente (cara a cara) o distribuidamente. Una caracterıstica importantees redistribuir la IU en los dispositivos de los colaboradores colocalizados; mientras que secentraliza la IU de los colaboradores reditribuidos, ası como proveerlos de la conciencia degrupo.

4.5.1 Preambulo

Los colaboradores no siempre trabajan de manera meramente co-localizada o distribuida, enalgunas ocasiones trabajan de manera hıbrida, i.e., algunos de manera co-localizada y otros


de manera distribuida en una misma sesion colaborativa. Algunos de los componentes quese muestran en la sesion actual de cada colaborador son susceptibles a ser modificados, porejemplo:

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

1. eliminar la foto y el nombre de los colaboradores que integran en ese momento el sub-grupo 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 de manera co-localizada y distribuida;

• el espacio de trabajo compartido en una sesion co-localizada podrıa ser desplegado en undispositivo con una pantalla lo suficientemente grande para que la informacion sea visiblea todos los integrantes. Por otra parte, el espacio de trabajo privado podrıa ser mostradoen el dispositivo personal de cada integrante;

• en una sesion co-localizada, las funcionalidades de un sistema colaborativo son mostradasdependiendo los roles de los colaboradores.

Para ejemplificar este escenario se usara la herramienta de votacion, la cual intenta facilitary agilizar el proceso de una sesion de votacion, permitiendo a los votantes sufragar de maneraelectronica, mediante sus dispositivos moviles, sin importar si se encuentran juntos en el lugarde reunion (co-localizados) o en un cualquier otro lugar (distribuidos). En dicha aplicacionse utiliza el termino “presente” para referirse a los colaboradores co-localizados y el termino“virtualmente presente” para referirse a los colaboradores distribuidos

Los roles que puede asumir un usuario en la herramienta de votacion son: 1) proponente, elcual le permite plantear una pregunta hacia un grupo de colaboradores y establecer las reglasde la sesion de votacion en curso y 2) votante, el cual le autoriza la emision de su voto durantedicha sesion.


Supongamos que Coello, el jefe del Departamento de Computacion de una universidad, orga-nizo una reunion en una sala de juntas que cuenta con un pizarron interactivo. El objetivo dela reunion es elegir al nuevo coordinador academico. Al llegar a la sala de juntas, cada partic-ipante es autenticado en el sistema ya sea: 1) de manera automatica a traves de NFC (NearField Communication) o 2) por medio de una ventana que le solicita su nombre de usuario ycontrasena. Al inicio de la reunion, solo algunos de los participantes estan fısicamente presentes.La informacion de consciencia sobre la presencia de los miembros no solo puede ser inferidade manera natural, sino que tambien es mostrada en el pizarron interactivo por medio de unabarra que presenta a los miembros ausentes y virtualmente presentes.

Capıtulo 4 99

Despues de unos minutos, dos de los miembros ausentes ingresan al sistema a traves deInternet desde el lugar donde se encuentran. En consecuencia, la barra de colaboradores seactualiza automaticamente, quitando su foto y nombre de la seccion de miembros ausentes ycolocandolos en la seccion de miembros virtualmente presentes.

Despues, Coello decide que la reunion de inicio y pasa a la zona donde se encuentran elpizarron interactivo para introducir la informacion correspondiente. Al acercarse a dicha zona,una etiqueta NFC detecta su presencia y, en respuesta, el sistema inicia automaticamente unanueva sesion. En el pizarron interactivo se muestra un mensaje que informa dicho evento y unaventana con las aplicaciones disponibles. Desde dicha ventana, Coello inicia la herramientade votacion, la cual le asigna el rol de proponente. Por medio del pizarron interactivo, Coellopuede plantear a todos los profesores presentes la pregunta principal por la cual se organizo lareunion, las opciones de respuesta y las reglas de la sesion de votacion.

Coello escribe la pregunta en el pizarron interactivo y establece que la votacion puede seranonima, i.e. los votantes pueden elegir si hacen publico o no su nombre de usuario al votar.Coello ademas determina que la votacion sera valida siempre y cuando haya votado al menosel 90% del total de los profesores del departamento (cf. Figura 4.11). Una vez que Coello haconfirmado la informacion sobre la votacion en el pizarron interactivo, cada dispositivo movilde los miembros fısica y virtualmente presentes recibe una notificacion de votacion. Cuando unmiembro selecciona dicha notificacion, la herramienta de votacion se inicia automaticamenteen su dispositivo movil y le asigna el rol de votante.

Figura 4.11: Datos de la votacion en curso ingresados por el proponente en el pizarron interac-tivo


La interfaz de usuario de dicha aplicacion es capaz de adaptarse a la configuracion del grupo(distribuido o co-localizado) y al rol de cada participante (proponente o votante).

Para los miembros presentes en la sala, dicha adaptacion consiste en mostrar en su dispositivomovil unicamente las posibles opciones de respuesta para la pregunta actual (cf. Figura 4.12b),ya que la descripcion de la misma es mostrada en el pizarron interactivo (cf. Figura 4.12a).En el caso de los miembros virtualmente presentes, la adaptacion consiste en mostrar en sudispositivo movil la pregunta, las opciones de respuesta y tres listas de consciencia de grupo: 1)miembros ausentes, 2) miembros virtualmente presentes y 3) miembros fısicamente presentes enla sala (cf. Figura 4.12c). En ambos casos, la aplicacion proporciona una opcion de abstenciony un boton para emitir un voto anonimo, debido a que Coello ası lo establecio.

La aplicacion da un tiempo de espera para que los profesores analicen las opciones disponiblesy emitan su voto. Al finalizar dicho tiempo, la aplicacion detecta que el porcentaje mınimopara validar la votacion no ha sido alcanzado, ası que decide mostrar en el pizarron interac-tivo un mensaje de aviso que proporciona las siguientes opciones: 1) validar la votacion conel porcentaje actual, 2) posponer la votacion (con el fin de alcanzar el porcentaje requeridoen otro momento) y 3) cancelar la votacion. Coello selecciona la primera opcion. Como re-sultado, la aplicacion muestra los resultados en el pizarron interactivo para que los presentespuedan visualizarlos (cf. Figura 4.13) y los envıa a los dispositivos moviles de los colaboradoresvirtualmente presentes (cf. Figura 4.14).

Tanto en el pizarron interactivo, como en los dispositivos moviles de los miembros virtual-mente presentes, los profesores pueden visualizar el porcentaje de votacion de cada opcion, asıcomo los nombres de quienes votaron por cada una de ellas. En el caso de los que votaron comoincognito, la palabra “anonimo” es mostrada en lugar del nombre de usuario. De esta manera,termina la sesion de votacion.

Adaptacion del contexto de uso de los sistemas colaborativos

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

La adaptacion al grupo de colaboradores se lleva a cabo cuando la herramienta de votaciondistingue entre un rol de proponente y un rol de votante puesto que la interfaz de usuario esdiferente para cada uno.

La adaptacion al conjunto de plataformas ocurre cuando el sistema sugiere a Coello usarel pizarron interactivo, ya que detecta que el esta cerca del dispositivo mencionado. Otra formade adaptacion a la plataforma consiste cuando la herramienta adapta su interfaz de usuario alos dispositivos moviles que estan usando los votantes.

La adaptacion al entorno comun se logra cuando la herramienta muestra quienes trabajande manera co-localizada (presentes) y de manera distribuida (virtualmente presentes) en labarra de colaboradores.

Capıtulo 4 101

(a) Pregunta sujeta a votacion y opciones detalladas de respuestamostradas a los participantes co-localizados en el pizarron interactivo

(b) Opciones simplificadas de re-spuesta en el dispositivo movil deun votante co-localizado

(c) Opciones detalladas de re-spuesta en el dispositivo movil deun votante distribuido

Figura 4.12: Adaptabilidad de la interfaz de usuario de la herramienta de votacion con base enla configuracion del grupo y el rol del usuario


Figura 4.13: Resultados de la votacion mostrados a los participantes co-localizados en elpizarron interactivo

Figura 4.14: Resultados de la votacion mostrados en los dispositivos de los participantes dis-tribuidos

Capıtulo 4 103

4.5.3 Herramienta de votacion

Como se menciono, esta herramienta permite crear votaciones electronicas aun cuando la ubi-cacion de los colaboradores sea distinta, i.e., co-localizada o distribuida, o los dispositivos en usosean heterogeneos, e.g., pizarron interactivo y dispositivo movil. Ademas, dicha herramientaofrece las funcionalidades necesarias dependiendo de dos variables: 1) el rol (votante o propo-nente) de cada participante y 2) el tiempo establecido para generar el voto.


A continuacion se presentan los requerimientos de la herramienta de votacion, con el fin deexpresar las caracterısticas y restricciones de la misma.

Los requerimientos funcionales de la herramienta de votacion son los siguientes:

• Identificar y asignar un rol a cada usuario con base en el tipo de dispositivo desde el cualaccede a la aplicacion.

• Adaptar su interfaz de usuario de acuerdo al rol y a la ubicacion fısica del usuario (i.e.,si esta presente o no en la sala de reunion).

• Permitir que el proponente organice una nueva votacion. En particular, se le debe permitirplantear una pregunta hacia un 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.

• Mostrar en los dispositivos moviles de los miembros virtual y fısicamente presentes, lasposibles opciones de respuesta a la pregunta de votacion, una opcion de abstencion y, sila votacion lo permite, una opcion de voto anonimo.

• Mostrar en los dispositivos moviles de los miembros virtualmente presentes la preguntaque fue sometida a votacion e informacion detallada sobre cada opcion de respuesta.

• Garantizar, siempre que sea posible, la igualdad entre las opciones de respuesta, sinfavorecer a ninguna.

• 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.

• Brindar al proponente la posibilidad de iniciar la votacion, lo cual hara posible que sepueda recibir y registrar los votos de los electores.


• Mostrar un tiempo de espera en el pizarron interactivo para que los miembros fısica yvirtualmente presentes emitan su voto.

• Solicitar al votante la confirmacion de su voto.

• Contabilizar los votos de los usuarios y calcular el porcentaje de votacion.

• Si no se alcanzo el porcentaje mınimo de votacion, la aplicacion debe mostrar opcionespara: 1) validar la votacion con el porcentaje actual, 2) posponerla o 3) cancelarla.

• Si se alcanzo el porcentaje mınimo o se valido la votacion manualmente, la aplicacion debemostrar los resultados en el pizarron interactivo y enviarlos a los dispositivos moviles delos miembros virtualmente presentes.

• Recuperar una sesion de votacion establecida como pospuesta.

• Eliminar toda la informacion de una sesion de votacion establecida como cancelada.

Los requerimientos no funcionales de la herramienta de votacion son en listados a contin-uacion:

• Almacenar los votos de tal manera que se garantice la privacidad de los mismos. No sepuede tener acceso a los votos almacenados, hasta que se produzca el cierre de la votacion.

• Transmitir la informacion de forma que se garantice la integridad y autenticidad de lamisma.

Interfaz de usuario

La adaptacion de la aplicacion al contexto de uso considera las siguientes variables contex-tuales: 1) deteccion de un colaborador, 2) aplicacion en ejecucion, 3) rol del colaborador y 4)configuracion del grupo.

La variable “deteccion de un colaborador” almacena el nombre del colaborador que estacerca al pizarron interactivo que ofrece las aplicaciones disponibles. En el caso de que dichocolaborador ejecute la herramienta de votacion (variable “aplicacion en ejecicion”) desde elpizarron, la herramienta de votacion le asigna el rol de proponente. Por consiguiente, el restode los colaboradores tendran el rol de votante.

La variable “rol de colaborador” sirve para desplegar la interfaz de usuario relacionada alrol. En el caso del rol de proponente, la interfaz de usuario contiene varios campos a llenar,e.g., tema, tiempo lımite para la votacion y porcentaje mınimo (cf. Figura 4.11). En el casodel rol de votante, se puede mostrar dos tipos de interfaces de usuario dependiendo de lavariable “configuracion de grupo” que puede tener una de las siguientes opciones: co-localizadoo distribuido.

Capıtulo 4 105

La interfaz de usuario de los votantes co-localizados tendra como opciones los nombres delos candidatos (cf. Figura 4.12b). Otra interfaz de usuario que visualizan estos votantes es lade resultados, la cual es desplegada en el pizarron interactivo (cf. Figura 4.13).

Mientras que los votantes distribuidos tendran dos interfaces de usuario, las cuales son lassiguientes: 1) interfaz de usuario de votacion, la cual tiene los nombres de los candidatos, unabarra de colaboradores que muestra la conciencia de grupo (presente, virtualmente presente yausente) y una breve descripcion de cada candidato (cf. Figura 4.12c) y 2) interfaz de usuariode resultados, la cual muestra de manera resumida el porcentaje que obtuvo cada candidato yde ser posible indica quien voto por dicho candidato (cf. Figura 4.14).

Es importante notar que las interfaces de usuario de los votantes distribuidos tienen masinformacion debido a que requieren tener la informacion completa respecto a la votacion yconciencia de grupo.


Por otro lado, para mostrar la manera en que la herramienta de votacion puede adaptarse acambios contextuales, se describe una lista de eventos que provocan la adaptacion de dichaaplicacion:

1. Un proponente inicia una nueva sesion de votacion: despues de que el proponenteselecciona la herramienta de votacion desde el pizarron interactivo (cf. Figura 4.6), semuestra una ventana donde puede ingresar la informacion referente a la votacion (cf.Figura 4.11). Una vez confirmada dicha informacion, los usuarios reciben en sus dis-positivos una notificacion de votacion. En el pizarron interactivo (cf. Figura 4.12a), losusuarios co-localizados pueden observar la pregunta, las opciones de respuesta, el tiempode espera y las reglas de la votacion, i.e., debe participar al menos el 90 % del total deusuarios registrados y los votantes pueden sufragar de manera anonima, pero no puedenabstenerse de votar.

2. Un votante fısicamente presente participa en la sesion de votacion en curso:cuando un participante fısicamente presente selecciona la notificacion de votacion, seejecuta la herramienta de votacion en su dispositivo. La interfaz de usuario de esta her-ramienta se adapta a fin de desplegar unicamente las posibles opciones de respuesta parala pregunta actual, y, si es el caso, una opcion para votar como anonimo y un botonde abstencion (cf. Figura 4.12b). En el pizarron interactivo, los votantes pueden obser-var informacion de consciencia de grupo, i.e., los colaboradores ausentes y virtualmentepresentes en la reunion (cf. Figura 4.6).

3. Un votante virtualmente presente participa en la sesion de votacion en curso:cuando un participante virtualmente presente selecciona la notificacion de votacion, seejecuta la herramienta de votacion en su dispositivo. La interfaz de usuario de la her-ramienta se adapta de manera que muestra tres listas de consciencia de grupo: 1) ausentes,


2) virtualmente presentes y 3) fısicamente presentes en la reunion; ademas, muestra lapregunta, sus opciones de respuesta e informacion adicional, e.g., si la votacion puedeser anonima o no. Cuando un participante presiona durante 1 o 2 segundos una de lasopciones de respuesta, se muestra un mensaje emergente que proporciona informacionadicional sobre la opcion seleccionada (cf. Figura 4.12c).

4. El tiempo de espera para emitir los votos termina: si la aplicacion detecta que sealcanzo el porcentaje mınimo de participacion, la votacion es establecida como validada.En caso de que no se haya alcanzado el porcentaje mınimo de votacion, la aplicacionmuestra un mensaje de aviso en el pizarron interactivo que proporciona las siguientesopciones: 1) validar la votacion con el porcentaje actual de votacion, 2) posponerla o 3)cancelarla.

4.6 Escenario 4: Mejoramiento de la conciencia grupal

Esta propuesta modifica el medio de contacto y la disponibilidad de dos colaboradores depen-diendo de sus actividades, preferencias y dispositivos en uso.

4.6.1 Preambulo

Los sistemas colaborativos permiten diferentes medios de contacto, e.g., el sistema de mensajerıainstantanea permite la comunicacion mediante texto, audio o video en tiempo real. Dichossistemas, e.g, la mensajerıa instantanea, no cambian de manera automatica los medios decomunicacion, i.e., no consideran la actividad, el dispositivo o la aplicacion en uso, lo cual obligaa los colaboradores tener que usar diferentes sistemas para llevar a cabo la comunicacion.

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


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 Isaactambien es responsable de escribir la seccion de introduccion. Finalmente, Alice y Sandy estanencargadas respectivamente de escribir y revisar la seccion de conclusiones, pero Alice tieneasignado la revision de la seccion de introduccion y de desarrollo.

Capıtulo 4 107

Isaac ingresa al espacio de trabajo para terminar algunas subsecciones de la seccion de de-sarrollo, ya que la fecha lımite de esta actividad esta relativamente cercana. Con base en laspreferencias de Isaac, el espacio de trabajo determina su disponibilidad como sigue:

1. Ocupado para los colegas: a) cuya actividad actual es muy poco similar o no similar a lasuya, aun si una de sus actividades potenciales es mas o menos similar o poco similar asu actividad actual, y b) cuya actividad actual o potencial es muy poco o no similares asu 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 actividades potenciales es similar o muy similar a su actual actividad.

3. Accesible para los colegas cuya actividad es similar o muy similar a la suya.

Entonces, Isaac define sus propios medios de contacto con base en sus sub-estados de disponi-bilidad (primer parametro de entrada):

1. Cuando esta ocupado, Isaac puede ser contactado por correo electronico, ası que temasno relacionados a su actividad actual seran tratados cuando el pueda/quiera.

2. En el caso de estar contactable si es posible, el podra ser contactado solo por mensajerıainstantanea para ser informado inmediatamente de algun tema y retrasar su respuesta encaso de ser necesario.

3. Cuando esta accesible, Isaac 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 de trabajo, ellas prefieren que este infiera sudisponibilidad y sus medios de contacto. Tanto Alice como Sandy deciden trabajar en laseccion de conclusiones, ası que ellas colocan su cursor en dicha seccion para empezar a escribiry redactar respectivamente. Dado que la fecha lımite de dicha actividad es relativamentedistante, el espacio de trabajo determina los siguientes sub-estado de su disponibilidad:

1. Ocupadas para colegas, cuyas actividades actuales y potenciales sean poco o no similaresa sus actuales actividades.

2. Contactable si es posible para colegas, cuya actual actividad es muy poco similar o nosimilar a la suya, pero una de sus actividades potenciales es muy similar, similar, mas omenos similar o poco similar a su actividad actual.

3. Accesibles para colegas, cuya actual actividad esmuy similar, similar, mas o menos similar,o poco similar a la suya.


Ademas, el espacio de trabajo establece el medio de contacto de Sandy con base en la similitudentre sus actividades y las de sus colegas, considerando las preferencias de Sandy. De estamanera, ella puede ser contactada a traves de:

1. Anotaciones privadas en el texto o correo electronico por colegas, cuya actividad actual opotencial es muy similar o similar a su actividada actual o potencial. En este caso, Sandyha seleccionado esos medios de contacto, ya que estos aseguran la persistencia de datos.

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 en funcion de 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.

Suponga que Sandy revisa la seccion de conclusiones durante un rato y despues detienesu actividad para contactar a Isaac. Ella coloca su cursor en la foto de Isaac (localizado enla barra de colaboradores) y como resultado, un ıcono desplegable aparece para mostrar ladisponibilidad de Isaac y los medios de contacto para comunicarse con el (cf. Figura 4.15a).Sandy nota que la disponibilidad de Isaac es contactable si es posible, ya que la fecha lımite desu actividad es cercana y aun cuando sus actividades en curso no son similares, ella tambien esresponsable de escribir la seccion de desarrollo. Por consiguiente, el medio de contacto de Sandypara comunicarse con Isaac es la mensajerıa instantanea. Sin embargo, ella decide terminar derevisar un parrafo de la seccion de conclusiones, antes de contactarlo. Cuando Sandy pone sucursor sobre la foto de Alice (cf. Figura 4.15a), ella observa que la disponibilidad de su colegaes accesible ya que aunque sus actividades actuales son poco similares, la fecha lımite de laactividad de Alice es distante. El medio de contacto que tiene Sandy para comunicarse conAlice es mediante anotaciones privadas sobre el texto porque ambas estan trabajando sobre lamisma seccion (cf. Figura 4.15a).

Isaac percibe que la disponibilidad de Sandy es ocupado (cf. Figura 4.15b), ya que aunquela fecha lımite de la actividad de ella es distante, sus actividades actuales no son similares yla actividad potencial de el (i.e., escribir la seccion de introduccion) tampoco es similar a laactividad actual de ella. Los medios de contacto de Sandy son las anotaciones privadas sobreel texto y el correo electronico porque la actividad potencial de ella (i.e, escribir la seccion dedesarrollo) es muy similar a la actividad actual de Isaac. La vista de Isaac muestra que Alice

Capıtulo 4 109

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.15: Disponibilidad y medios de contacto al inicio de la sesion colaborativa.

es accesible (cf. Figura 4.15b), ya que la fecha lımite de la actividad de ella es distante y susactividades actuales son mas o menos similares. Los medios de contacto disponibles para queIsaac contacte a Alice son video-conferencia, voz y mensajerıa instantanea porque ellos estantrabajando en diferentes secciones.

Al igual que Sandy, Alice puede ver que la disponibilidad de Isaac es contactable si es posible(cf. Figura 4.15c), ya que la fecha lımite de la actividad de el es cercana y sus actividadesactuales son mas o menos similares. Por lo tanto, los medios de contacto disponibles para queAlice establezca comunicacion con Isaac corresponden a la mensajerıa instantanea. A diferenciade la vista de Isaac, la vista de Alice (cf. Figura 4.15c) muestra que Sandy es accesible, ya queaunque sus actividades actuales son poco similares, la fecha lımite de la actividad de Sandyes distante. Los medios de comunicacion disponibles para que Alice contacte a Sandy son lamensajerıa instantanea y voz porque sus actividades actuales y potenciales son mas o menossimilares en el mejor de los casos.

Despues, Sandy 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 de trabajo detecta esta accion, no solo los sub-estados de la disponibilidad de Sandycambian sino tambien los de sus colegas cono se explica a continuacion. Para llegar a un acuerdoacerca de la estructura de esta seccion, Sandy pone su cursor en la foto de Isaac otra vez yobserva que su estado de disponibilidad se volvio accesible (cf. Figura 4.16a). Ella tambien nota


que tiene medios de contacto adicionales para comunicarse con el. De hecho, la instancia delespacio de trabajo alojado en el dispositivo de Sandy provee esos medios de contacto adicionalesporque este ha detectado que Sandy e Isaac estan compartiendo la misma actividad.

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.16: Disponibilidad y medios de contacto de Sandy, Isaac y Alice una vez que Sandyha cambiado su actividad.

De esta manera, los medios de contacto disponibles para que Sandy establezca comunicacioncon Isaac son voz y mensajerıa instantanea, ya que aun cuando Isaac tambien establecio la her-ramienta de video-conferencia como uno de sus medios de contacto preferidos y su dispositivoes capaz de soportarlo, el dispositivo de Sandy no tiene camara. En consecuencia, una sesionde video conferencia no puede llevarse a acabo. En la vista de Sandy (cf. Figura 4.16a), Alicepermanece accesible, ya que la fecha lımite de la actividad de Alice es distante y sus actividadesactuales son mas o menos similares. Sin embargo, los medios de contacto de Alice han cambi-ado a mensajerıa instantanea y voz porque ellas estan trabajando en diferentes secciones. Esimportante mencionar que la herramienta de video-conferencia ha sido seleccionada por Alice,pero no esta disponible para Sandy ya que como se menciono previamente, el dispositivo deSandy no tiene camara.

En la vista de Isaac (cf. Figura 4.16b), Sandy se volvio accesible, ya que sus actividadesactuales son muy similares. Por este motivo, los medios de comunicacion disponibles para queIsaac contacte a Sandy permanecen sin cambios. La disponibilidad y los medios de contactode Alice son los mismos. Por otro lado, en la vista de Alice (cf. Figura 4.16c), los medios decontacto y la disponibilidad de Isaac permanecen sin cambios, pero Sandy se volvio contactable

Capıtulo 4 111

si es posible ya que las actividades actuales de Alice y Sandy son mas o menos similares y lafecha lımite de la actividad de Sandy es cercana. Es importante mencionar que los mediosde contacto de Sandy no cambiaron, porque sus actividades actuales y potenciales son mas omenos similares en el mejor de los casos.

Adaptacion del contexto de uso de los sistemas colaborativos

Este escenario aborda dos dimensiones del contexto de uso de los sistemas colaborativos. 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 consideran los dispositivosnecesarios para proveer el servicio de medios de contacto. En el caso de Isaac, el si contabacon una camara Web para realizar una video-conferencia, pero Sandy no tenıa camara, por talmotivo el sistema no ofrecio dicho servicio.

4.6.3 Herramienta disponibilidad y medios de contacto

Esta herramienta tiene como finalidad adaptar la disponibilidad y los medios de contacto de-pendiendo del colaborador a contactar (colaborador observado) y el que desea hacer el contacto(colaborador observador). Tanto la disponibilidad como el medio de contacto pueden ser cal-culados de manera automatica, dependiendo de las actividades, roles y la disponibilidad de loscolaboradores involucrados o de manera manual por parte del colaborador.


Los requerimientos funcionales de la herramienta de disponibilidad y medios de contacto seenlistan a continuacion:

1. Autenticar a los colaboradores.

2. Permitir que los colaboradores establezcan manualmente su disponibilidad desde la ven-tana de configuracion de disponibilidad.

3. Calcular la disponibilidad de manera automatica mediante el mecanismo de similitud delas actividades potenciales y actuales del colaborador observado y del observador.

4. Permitir que los colaboradores establezcan su medio de contacto de manera manual me-diante la ventana de configuracion de los medios de contacto. Los medios de contacto


corresponden a: video-conferencia, correo electronico, audio, mensajerıa instantanea yanotaciones privadas. Cada medio de contacto sera relacionado con un estado de disponi-bilidad, ası que cuando se calcule la disponibilidad, los medios de contacto relacionadosestaran disponibles para el colaborador observador.

5. Calcular los medios de contacto de manera automatica.

6. Mostrar la disponibilidad y el medio de contacto del colaborador observado al momentode que el colaborador observador coloque el cursor sobre la foto del observado.

7. Abrir el medio de contacto seleccionado por el observador cuando requiere contactar alcolaborador observado.

8. Verificar que ambos tengan el hardware como el software necesario para un medio decontacto dado;

Los requerimientos no funcionales de la herramienta disponibilidad y medios de contacto semuestran a continuacion:

1. Verificar el hardware y software necesario para los medios de contacto en un tiempo muybreve, escasos segundos;

2. Calcular la disponibilidad en un tiempo breve, escasos segundos;

3. Informar al colaborador la razon por la que no puede utilizar un medio de contactoespecıfico.


Las variables contextuales involucradas en la adaptacion de la disponibilidad y los medios decontacto son las siguientes: 1) similitud de las actividades, 2) disponibilidad, 3) dispositivo enuso y 4) preferencias del colaborador observado. Las variables anteriores son necesarias tantopara la disponibilidad como los medios de contacto, aunque estos ultimos tambien requieren ladisponibilidad y las preferencias del usuario. Dichas variables estan planteadas a detalle en lapropuesta del escenario 4.6.

La variable “similitud de las actividades” almacena el grado de similaridad entre las activi-dades, el cual corresponde a muy similares, similares, mas o menos similares, poco similares,muy poco similares y no similares. Este calculo requiere la actividad actual del colaboradorobservado y del observador.

La variable “dispositivos en uso” debe contener tanto el hardware como el software deldispositivo en uso del observador y del colaborador observado, con la finalidad de ofrecer o noun medio de comunicacion en especıfico.

Capıtulo 4 113

La variable contextual “disponibilidad”, solo es requerida para calcular el medio de contacto;dicha variable acepta uno de los siguientes estados: ocupado, accesible y alcanzable si es

posible. A partir de esta variable, la de similitud y la de dispositivos en uso ofrecen los mediosde contacto disponibles entre dos colaboradores.

La variable “preferencias del colaborador observado” contiene la predileccion de medios decontacto. Dicha preferencia debe ser previamente establecida por el o por algun mecanismo delsistema.


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 la manera en que la herramienta puede adaptarse acambios contextuales:

1. Un colaborador prefiere que el espacio de trabajo determine su disponibilidady medio de contacto. En este caso el colaborador omite abrir la ventana de disponi-bilidad, lo cual indica al espacio de trabajo que deba determinar automaticamente ladisponibilidad del colaborador.

2. Un colaborador coloca su cursor en la foto de otro colaborador. En consecuencia,la barra de colaboradores despliega varios widgets que muestran la disponibilidad y losmedios de contacto del colaborador observado (cf. Figuras 4.15 y 4.16).

3. El colaborador observador selecciona un medio para contactar al colaboradorobservado. Despues de seleccionar el medio de contacto, este es ejecutado para ser usadopor ambos colaboradores.

4.7 Escenario 5: Manejo de intromisiones

Esta propuesta oculta informacion de manera automatica ante la presencia de una personaajena al grupo de colaboracion.

4.7.1 Preambulo

En los ultimos anos, la cobertura del servicio de Internet se ha ido incrementando, lo cual hapermitido que los usuarios de ese servicio puedan comunicarse facilmente. Dentro del grupode estos beneficiarios se encuentran los usuarios de los sistemas colaborativos. Gracias a la


cobertura de Internet y a los dispositivos moviles, tales como PC portatiles o tablets, los colab-oradores pueden trabajar fuera de sus oficinas.

El problema de trabajar fuera de las oficinas es que los colaboradores pueden acceder ainformacion 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 de que una persona ajena se acerque al dispositivoes la interrupcion de la comunicacion, e.g., video llamada que esta llevando a cabo de maneraelectronica.


Supongamos que una empresa de desarrollo de software recibio un reporte de errores en unsistema de administracion que ellos implementaron. Dada la gravedad del problema, la empresalanzo una convocatoria a todos sus desarrolladores con la finalidad de encontrar y proponeruna solucion a dichos errores de software.

Un grupo de colaboradores, compuesto por Sandy, Alice e Isaac, encontraron el problema endicho software. Ası que ellos decidieron hacer un documento explicando tanto las causas de loserrores encontrados como la solucion propuesta.

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 las causas de loserrores encontrados, Isaac debe hacer y describir los diagramas de clase y Alice tiene que hacery redactar los 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 restaurante de laempresa. Ella decide empezar a trabajar en la redaccion del documento mientras espera que leentreguen su comida. Cuando ella va a la mitad de la redaccion, le surgen dudas de los erroresencontrados en el software, ası que ella decide entablar una comunicacion con el resto del grupopor medio de la mensajerıa instantanea. Mientras el grupo de trabajo esta participando enla conversacion, Sandy puede ver en su pantalla tanto el documento que estan generando asıcomo la conversacion del grupo.

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 tanto lascausas de los errores como la solucion al problema de software, por tal motivo el decide acercarsea la computadora portatil de ella para intentar leer tanto el reporte como su conversacion conel equipo. Tan pronto como el programador se acerca a la computadora, el sistema detectaque una persona ajena al grupo esta observando de frente la pantalla de la computadora de

Capıtulo 4 115

Sandy. Como consecuencia, el sistema oculta tanto el reporte como la conversacion que ellaesta llevando a cabo.

Por otro lado, Alice responde a la pregunta generada por Sandy, pero observa que Sandyno responde a la explicacion dada. De repente Alice nota que la foto de Sandy cambio decolor. Cuando Alice ubica su cursor del raton sobre la foto de Sandy, el sistema muestra unmensaje indicando que una persona ajena al grupo esta observando la pantalla de Sandy. Portal motivo ella no puede observar los mensajes enviados ni las actualizaciones, ni tampocopuede desarrollar sus actividades.


Este escenario solo se adapta a la dimension entorno compartido, la cual pertenece al con-texto de uso de los sistemas colaborativos. Tal adaptacion se logra cuando se detecta a 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: Suministro de informacion relevante

Esta propuesta provee informacion tomando en cuenta el contexto del colaborador considerandolos dispositivos en uso, las actividades en ejecucion y la informacion a desplegar.

4.8.1 Preambulo

En este caso, la adaptacion de la informacion se refiere al despliegue de esta, 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 en el momento en que se genera, como en el caso delas reuniones de trabajo;

• rol: determina las restricciones y alcances que tiene el colaborador en el manejo de lainformacion;

• actividad: concierne a el suministro de informacion que enriquezca la actividad actualdel colaborador, e.g., proveer manuales de diagramas de clase a un colaborador que estahaciendo dichos diagramas;


• conjunto de plataformas: se refiere a considerar tanto el hardware como el software nece-sario para soportar el despliegue de la informacion;

• tamano de los archivos: es 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 ser utilpara el colaborador considerando su ubicacion actual;

• preferencias sobre la informacion: se refiere a que dada las preferencias del colaboradorpuede recibir informacion relacionada.

El siguiente escenario maneja dos herramientas, las cuales son: administracion de contenidosy consultas de pacientes. La primera herramienta facilita informacion que se tratara en unareunion previamente planificada. La segunda herramienta lleva el control de los pacientes,i.e., ya que contiene los resultados de laboratorios y estudios, ası como las anotaciones de losmedicos, enfermeras y especialistas.


Supongamos que Sandy, Alice e Isaac estan registrados en el sistema de consultas de pacientesen un hospital, cada uno de ellos tienen los siguientes roles: Isaac es medico cardiologo, mientrasque Alice es pasante de medicina y Sandy es enfermera.

Dado que Alice es pasante de medicina, el Dr. Isaac quiere que ella deduzca el padecimientode cinco pacientes, ası que el agenda una cita con Alicia en la sala de medicos. Isaac entra ala habitacion dos hora antes de la hora acordada, con el fin de establecer algunos detalles de lareunion. En su tablet PC, el Dr. Isaac ejecuta la herramienta de administracion de contenidos,con el fin de establecer cada asunto a discutir (visita a los pacientes de los cuartos 2, 8, 15,18 y 19) y seleccionar los expedientes de los pacientes a visitar. Dichos expedientes son unaversion resumida que es generada por la herramienta de consulta de pacientes. Al final deeste proceso, el Dr. Isaac acerca su dispositivo movil a la etiqueta NFC situada en la entradade la sala de reuniones y selecciona la opcion que le permite grabar la informacion sobre lareunion en dicha etiqueta. Debido a las limitaciones de almacenamiento de las etiquetas NFC,la herramienta de administracion de contenidos sube a un servidor de contenidos, a traves deWi-Fi, los expedientes de los pacientes en los formatos disponibles (e.g., html, pdf, doc).

Alice llega una hora antes a la sala de medicos y acerca su tablet PC a la etiqueta NFC, detal manera que cuando la distancia entre ambos es de 3 cm o menos, se establece entre ellosuna comunicacion a traves de NFC. Como resultado de dicha comunicacion, varias accionestienen lugar automaticamente: 1) la herramienta de administracion de contenidos es lanzadaen ejecucion, 2) la sesion del participante es iniciada, y finalmente 3) la etiqueta NFC transfierea su dispositivo movil la informacion necesaria. Una vez finalizado este proceso, en la interfaz de

Capıtulo 4 117

usuario del administrador de contenidos se anaden ıconos que representan los documentosdescargados, con el fin de que sean facilmente accesibles por el usuario. Ası que a la hora de lareunion Sandy ya tiene dichos expedientes.

Con el fin de descargar documentos adaptados a las caracterısticas del dispositivo, la her-ramienta de administracion de contenidos toma en cuenta el espacio de almacenamiento y losvisores de documentos disponibles en el dispositivo. De esta manera, por ejemplo, si no hay su-ficiente espacio de almacenamiento para guardar todo el documento, se proporciona unicamenteun resumen. Del mismo modo, si el dispositivo destino tiene solo visores postscript, un docu-mento en este formato es descargado desde el servidor de contenidos a traves de Wi-Fi.

Posterior a la reunion, Sandy y Alice deciden consultar a los pacientes que habıan discutido.El recorrido empieza por las patologıas mas comunes, en este caso por el paciente del cuarto 18.Al ingresar al cuarto, la herramienta de consulta de pacientes detecta la presencia de ambas endicho cuarto; en consecuencia el sistema propone al Dr. Isaac delegar algunas responsabilidadesa Alice, pero el declina la sugerencia ya que el piensa que ella necesita practicar mas.

Otra accion por parte la herramienta de consulta de pacientes es desplegar en ambas tablets elexpediente completo del enfermo del cuarto 18. Para el Dr. Isaac es normal tener el expedientedel paciente que visita; en cambio, Alice se sorprende porque ella tenıa previamente a la vista elexpediente resumido del paciente del cuarto dos, puesto que ella penso el recorrido en un ordenascendente. Tanto Alice como el Dr. Isaac pueden ver los resultados de los estudios clınicos.Terminando la visita, el Dr. Isaac agrega anotaciones y modifica la dosis de medicamento,gracias a la mejora del paciente, en el expediente del enfermo. Alice puede ver a traves de sutablet la serie de pasos que el Dr. Isaac hace al momento de modificar el expediente.

Al momento que la dosis es modificada, la herramienta de consulta de pacientes actualiza lainformacion en la base de datos, posterior a la actualizacion de la base de datos se informa dedicha actualizacion al demas personal que atiende al paciente de la cama 18, e.g., la nueva dosisde medicamento se notifica a Sandy y la mejora en la salud del paciente se notifica al nutriologo.La actualizacion de la dosis es de manera inmediata ya que esta es de vital importancia debidoa que una dosis no apropiada puede tener consecuencias fatales en la salud del paciente.

En las visitas a los cuartos 8 y 19, Alice continua dando sugerencias verbales y observandocomo el Dr. Isaac manipula la herramienta de consulta de pacientes. Cuando ambos llegan alcuarto 15, el Dr. Isaac permite que Alice haga anotaciones relacionadas con el paciente usandola herramienta mencionada. Por tal motivo, ambos tienen derechos de modificar el expedientede dicho paciente.

Finalmente, tanto Alice como el Dr. Isaac acuden al cuarto 2 en donde Sandy esta tomandolos signos vitales del paciente. Cuando ellos ingresas al cuarto, la informacion de los signosvitales es actualizada inmediatamente en las tablets de Alice e Isaac. Al momento que elsistema detecta que ambos estan en el cuarto, el sistema propone dos opciones: 1) delegaralgunas responsabilidades a Alice o 2) usar la computadora tactil ubicada sobre la pared conla finalidad de que ambos vean la misma informacion al mismo tiempo. Ambas opciones


solo son desplegadas al Dr. Isaac desde su tablet ya que el tiene mayor jerarquıa que Alice.Isaac accede a las dos opciones, por tal motivo Alice puede modificar el expediente bajo lasupervision del doctor. Por otro lado, la herramienta consulta de pacientes despliega todas losecocardiogramas y electrocardiogramas en la computadora tactil, ya que es muy usual dichapreferencia por los usuarios del hospital mencionado. Mientras que las tablet solo contienen lasanotaciones medicas.

Al terminar las visitas tanto Sandy como Isaac continuan con sus actividades, por tal motivola herramienta de consulta de pacientes no permite que Alice consulte los expedientes de lospacientes visitados; en cambio, el Dr. Isaac tiene acceso total en cualquier momento, mientrasel se ubique dentro del hospital. En otros lugares, el Dr. Isaac no puede ver informacionrestringida, e.g., anotaciones del nutriologo.


Este escenario aborda todas las dimensiones del contexto de uso de los sistemas colaborativos.La adaptacion al grupo de colaboradores se implementa al proveer informacion relacionadacon los estratos de los colaboradores en el hospital, e.g., el Dr. Isaac tiene el control que permitela intervencion de Alice dentro del sistema del hospital. Tambien adapta a las preferencias delos usuarios,e.g., el Dr. Isaac decidio que el sistema le provea de informacion de los expedientes,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 queesta dimension ha sido llevada a cabo mediante la herramienta de consulta de pacientes aldetectar el espacio de almacenamiento y los visores disponibles.

La adaptacion al entorno compartido se aprecia en este escenario, ya que se considera,el lugar (proveer la informacion solo cuando los colaboradores esten dentro del hospital, asıcomo mostrar en la pantalla de los dispositivos moviles de los colaboradores el expediente delpaciente que estan actualmente visitando) y el tiempo (proveer la informacion una hora antesde la reunion).

4.8.3 Herramienta administrador de contenidos vıa NFC

Este escenario considera dos herramientas, administracion de contenidos y sistema de consultasde pacientes. En este caso solo se ha implementado la primera, la cual permite facilitar a ungrupo de colaboradores la informacion que se tratara en una reunion previamente planificada.Dicha informacion se refiere al objetivo de la reunion, los temas a tratar y los archivos relevantesa la misma. Al entrar al lugar de reunion y acercar su dispositivo movil a la etiqueta NFCasociada a dicho lugar, los colaboradores reciben automaticamente toda la informacion necesariasobre la reunion.

Capıtulo 4 119


Los requerimientos funcionales del administrador de contenidos vıa NFC se listan a contin-uacion:

1. Permitir que un colaborador ingrese la informacion relacionada a una reunion y suba aun servidor de contenidos, los documentos que son relevantes a la misma.

2. Permitir que un colaborador pueda grabar en una etiqueta NFC la informacion relacionadaa una reunion.

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. Ejecutarse automaticamente cuando un colaborador inicie su sesion a traves de una eti-queta NFC y haya informacion sobre una reunion grabada en dicha etiqueta. Detectarque tipos de formato de documentos son soportados por las herramientas de visualizacioninstaladas en el dispositivo.

5. Iniciar la descarga de los documentos que es necesario revisar durante una reunion. Du-rante la solicitud de documentos, se debe indicar que tipos de formato son soportados, detal manera que los documentos a descargar sean en un formato soportado.

6. Mostrar en la interfaz de usuario de la aplicacion un ıcono por cada documento descargadoy permitir la apertura de dicho documento al hacer clic sobre su ıcono.

Los requerimientos no funcionales del administrador de contenidos vıa NFC son los siguientes:

1. Habilitar el adaptador de red inalambrico WI-Fi, si este se encuentra deshabilitado.

2. Permitir la apertura de los documentos descargados.

3. No permitir la transmision de informacion a dispositivos de usuarios que no esten reg-istrados.


Las variables contextuales en la herramienta administrador de contenidos vıa NFC son lassiguientes: 1) tiempo, 2) visores disponibles y 3) espacio de almacenamiento.

La variable contextual “tiempo” determina la informacion que es susceptible de ser descar-gada. Por otro lado, la variable “visores disponibles” permite conocer los visualizadoresdisponibles en el dispositivo del usuario y de esta forma determinar el formato de los doc-umentos que podran ser desplegados. Finalmente, la variable “espacio de almacenamiento”determina que version de los documentos podran ser descargados; previamente deben estarregistrados dos o mas versiones del mismo documento.



Con el fin de mostrar la manera en que el administrador de contenidos puede adaptarse alos cambios contextuales, se describe una lista de eventos que provocan la adaptacion de estaherramienta:

1. Un colaborador ingresa a una sala de juntas y acerca su dispositivo (a unadistancia de 3 cm o menos) a una etiqueta NFC: la etiqueta transfiere al dispositivodel usuario la informacion referente a la reunion en curso. A continuacion, se ejecuta elmodulo de lectura de la aplicacion, cuya interfaz de usuario es adaptada de acuerdo a lainformacion recibida, i.e. muestra la lista de puntos a tratar en la reunion e informacionadicional correspondiente a cada uno de ellos. Finalmente, el modulo de lectura inicia ladescarga de los documentos a revisar durante la reunion.

2. El modulo de lectura de la aplicacion detecta que tipos de formatos de doc-umento son soportados por las herramientas de visualizacion del dispositivo:durante la solicitud de descarga de cada documento, el modulo de lectura indica los for-matos de documento soportados por el dispositivo, de tal manera que el documento adescargar tenga un formato soportado (si esta disponible).

3. Termina la descarga de los documentos a revisar durante la reunion: la interfazde usuario de la aplicacion muestra, junto a cada tema de la reunion, los documentosasociados a cada uno. Por medio de un clic sobre uno de los ıconos se puede visualizar elcontenido del documento correspondiente.

4.9 Escenario 7: Notificaciones multi-modales

Este escenario provee notificaciones de diversas modalidades para que dichos avisos se adaptenal contexto.

4.9.1 Preambulo

La multi-modalidad nos permite dar a conocer la llegada de informacion de diferentes formasdependiendo del tipo de informacion a notificar, del lugar en donde se encuentra ubicados loscolaboradores e incluso de las personas a nuestro alrededor. Las notificaciones multi-modalesmas usadas en los celulares son por: sonido, 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:

Capıtulo 4 121

• la relevancia de la informacion, e.g., la notificacion del cambio de medicamento de unpaciente hospitalizado es mas importante para una enfermera que recibir la notificacionde un dispositivo cercano que permite hacer video-llamadas;

• la actividad del colaborador que origina la notificacion y la del colaborador que recibe lanotificacion son importantes;

• el lugar fısico en donde se encuentra el receptor de la notificacion.


Sandy, Alice e Isaac pertenecen al equipo de desarrollo de software de una empresa renombrada.Sandy y Alice estan exponiendo a los clientes los avances del proyecto. Mientras tanto, Isaacesta terminando una actividad con fecha lımite caducada que no podıan resolver. La actividadmencionada es importante, ya que es parten de los avances a presentar frente a los clientes.

Los miembros del grupo de desarrollo utilizan un sistema que informa mediante notificacionesacerca de las modificaciones y las actividades concluidas en las que esta participando el grupo.

Antes de emitir la notificacion, el sistema determina el modo de la notificacion considerandolas siguientes caracterısticas: 1) la actividad actual tanto de Alice como de Sandy correspondea exponer los avances del proyecto, 2) las colaboradoras se encuentran en una sala de juntas conpersonas ajenas al proyecto, 3) la conclusion de la actividad de avances del proyecto ya que estaactividad es de importancia para ellas, 4) los dispositivos que estan usando los colaboradores;en este caso cada uno de ellos tiene un telefono celular, ası como dos computadoras portatiles,una de ellas es utilizada por Isaac, mientras que la otra es 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 la recibieron al mismotiempo. Dicha noticia informa de la conclusion de la actividad pendiente, la cual puede sermostrada 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 laparte inferior derecha de la pantalla un recuadro que contiene el anuncio. El sistema hace lanotificacion mediante la computadora que tiene en uso Isaac en su oficina-, la seleccion de dichodispositivo se debe a la poca relevancia de la actividad ası como la fecha lımite de la actividad.

Isaac quiere saber sobre los resultados de la presentacion a los clientes, por tal motivo elorganiza una reunion en su oficina mediante una agenda colaborativa. El establece el lugarde reunion su oficina. Por tal motivo, la agenda informa a Sandy y Alice de dicha reunionde manera textual, mediante sus telefonos celulares. En esta ocasion, el sistema utiliza nue-vamente la vibracion del celular ademas de aumentar el timbre de la notificacion, ya que ellas


temporalmente no estan desarrollando ninguna actividad y se encuentran en los pasillos deledificio.

Despues de la reunion con Isaac, las colaboradoras se dirigen cada una a sus respectivas ofici-nas para continuar trabajando en las actividades asignadas. Sandy se encarga de los diagramasde clase, ası que ella no requiere recibir las notificaciones de actualizacion del diagrama deestado ni que se realicen automaticamente las actualizaciones de dichos diagramas (suponiendoque el dispositivo de computo no cuente con los recursos necesarios de espacio en disco duro,poca memoria 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 decida ver los diagramas deestados 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 colaborativos. 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 Sıntesis

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 sistemascolaborativos. Ambas dimensiones incluyen el perfil, las actividades y los roles; la diferenciaradica en que la adaptacion al usuario modifica las necesidades y preferencias de un solo usuario,i.e., solo la instancia del sistema de dicho usuario se ve afectado sin modificar las instanciasde los demas usuarios; mientras que la adaptacion al grupo de colaboradores puede mod-ificar el comportamiento del sistema usado por todos los colaborador, e.g., un usuario puedeestablecer el medio de contacto para que sus colegas lo contacten dependiendo su actividad yla plataforma del colaborador observado y observador.

El contexto de uso de los sistemas colaborativos afectan a todos los colaboradores que estanconectados al sistema, e.g., en el escenario “mejoramiento del trabajo colaborativo” se permiteligar objetos compartidos, los cuales han sido creados desde diferentes aplicaciones, mediante

Capıtulo 4 123

referencias HTML; ası como notificar a los colaboradores cuando hacen uso de manera directao indirecta del mismo objeto.

Los escenarios mostrados en este capıtulo nos permiten dar una idea de las adaptacionesdel contexto de uso de los sistemas colaborativo. Dichas adaptaciones se hacen al grupo decolaboradores al considerar sus preferencia relacionadas a los medios de adaptacion (cf. Seccion4.6), dependiendo del rol se puede mostrar los iconos relacionados a su rol (cf. Seccion 4.4),informacion necesaria dependiendo de la actividad en curso (cf. Seccion 4.8) o en otras oca-siones ocultar dicha informacion que puede ser confidencial (cf. Seccion 4.7). Otra adaptacional colaborador es presentar notificaciones usando diferentes modalidades dependiendo de laactividad o del entorno en donde se ubica (cf. Seccion 4.9).

Dichos escenarios no solo cubren la dimension grupo de colaboradores, tambien cubren as-pecto de la dimension plataforma, ya que algunos de ellos identifican cuando el grupo decolaboradores tiene un conjunto de dispositivos; por ejemplo, activar el medio de contacto devideo-conferencia dependiendo de si los colaboradores tienen una camara en uso, de otra manerano vale la pena ofrecer el servicio (cf. Seccion 4.6), o permitir usar el disco duro de un colab-orador cuando el dispositivo en uso no tenga suficiente espacio para almacenar la informacion(cf. Seccion 4.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 de si el trabajo es co-localizado o distribuido (cf. Seccion 4.5) o la deteccion de lapresencia de una persona no autorizada para ver informacion restringida (cf. Seccion 4.7).

Algunas de las propuestas mencionadas en los escenarios han sido implementadas en lasherramientas desarrolladas. Por ejemplo, adaptar los iconos dependiendo del rol del colaborador(cf. Secciones 4.4.3 y 4.3.3), de si el trabajo es co-localizado o distribuido (cf. Secciones 4.5.3,4.8.3 y 4.4.3).

Uno de tantos problemas detectados y no resueltos en este tema de investigacion se refierea que funcionalidades debe ofrecer una aplicacion colaborativa cuando detecte que un grupode colaboradores trabajan de manera co-localizada, usan un dispositivo compartido, e.g., unpizarron interactivo, y dichos colaboradores tienen roles diferentes. La aplicacion colaborativadebe decidir que funcionalidades de la aplicacion mostrar. El sistema puede resolver de variasmaneras el problema anterior, las cuales son:

• combinar las funcionalidades dados los roles de los colaboradores, i.e., unir los ıconos quetienen acceso cada uno, sin duplicar estos;

• mostrar en el pizarron interactivo las funcionalidades que coinciden, dejando en sus dispos-itivos personales, en caso de tener estos, los ıconos que quedaron fuera de la interseccionde sus roles;

• en caso de que el sistema no pueda tomar una decision, este debe proponer a los colab-oradores las opciones por medio de una meta-interfaz de usuario para que ellos elijan la


mas adecuada.

Capıtulo 5

Diseno del marco XARE

En este capıtulo se describen los disenos horizontal y vertical del marco XARE. El disenovertical, que se explica 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 soportes contextuales en sus aplicaciones.

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. Todosestos mecanismos contienen los parametros de entrada necesarios, las clases involucradas, asıcomo los elementos susceptibles de ser modificados.

El diseno horizontal se aborda en la seccion 5.3 y se refiere a las capas del marco XARE, elcual propone adaptar los sistemas colaborativos a diferentes contextos de uso. Este marco surgea partir de la creacion y el analisis de los escenarios mostrados en el capıtulo 4, los cuales nospermitieron identificar en una primera version las tres capas sin mucho detalle. Dicha versionconsidera los percutores de adaptacion (remodelacion y redistribucion) y la participacion delos colaboradores durante el proceso de adaptacion (meta-interfaz con o sin negociacion), yevita en todo momento la perdida de sus contribuciones (recuperacion del sistema). Posteriora la implementacion de algunas aplicaciones se identificaron los modulos de Disponibilidad,Actividad Actual y Proximidad Logica pertenecientes a la capa de Deteccion. Otra contribucionimportante fue la incorporacion del modulo referente al espacio de Trabajo Privado y Publico.

Finalmente, en la seccion 5.4 se presenta una sıntesis del presente capıtulo.

5.1 Diagramas de clases

El modelado del contexto de uso se puede hacer de diversas maneras, e.g., ontologıas[Ejigu et al., 2007], grafos contextuales [Kouadri and Brezillon, 2004], teorıa de actividad[Kofod-Petersen and Cassens, 2006], logica proposicional de contexto [Buvac et al., 1995],

125

126 Diseno del marco XARE

semantica de modelo local/sistemas multicontexto [Serafini and Bouquet, 2004] y diagramasde clases [Derntl and Hummel, 2005]. Para modelar el contexto de uso de los sistemas colabo-rativos, se eligio los diagramas de clases, ya que estos permiten llevar a cabo la implementaciondel soporte contextual mediante lenguajes de programacion orientado a objetos. Ademas, estosdiagramas han sido utilizados para llevar a cabo la modelacion visual de conceptos del mundoreal, con el fin de reducir la complejidad y la carga cognitiva durante la etapa de diseno desistemas [Henricksen et al., 2002, Derntl and Hummel, 2005].

5.1.1 Contexto de uso de los sistemas colaborativos

Como se menciono en el capıtulo 4, el contexto de uso de los sistemas colaborativos se forma delos componentes grupo de colaboradores, conjunto de plataformas y entorno comun.En la Figura 5.1, se muestra que el contexto de uso de los sistemas colaborativos ha sidomodelado mediante el patron de diseno Decorator, el cual permite definir dinamicamentenuevos contextos de uso (clase abstracta ContextOfUse) para hacer que un sistema colaborativose adapte a cambios contextuales (clase abstracta AdaptativeGroupwareSystem). Gracias ala estructura de clases abstractas y concretas del patron de diseno Decorator, dicho sistemacolaborativo no necesita ser modificado por completo. De este modo, es posible que cualquiersistema colaborativo no adaptativo (clase ConcreteGroupwareSystem) se vuelva consciente devarios contextos de uso (clases ContextOfUse 1 ... ContextOfUse n).

Los diferentes contextos de uso pueden incluir todos o algunos de los componentes deadaptacion (grupo de colaboradores, conjunto de plataformas y entorno comun)dependiendo de los requerimientos del sistema. De esta manera, este patron estructural proveea los programadores un soporte flexible de desarrollo que les permite enriquecer sus sistemascolaborativos con capacidades de adaptacion, involucrando algunos o todos estos componentes(clases GroupOfCollaborators, SetOfPlatforms y CommonEnvironment).

La Figura 5.1 muestra un grupo de colaboradores (clase GroupOfCollaborators) que estacompuesto por al menos un colaborador (clase Collaborator) quien tiene un perfil y variosroles. De acuerdo a Gauch et al., un perfil (clase Profile) permite definir las habilidades ypreferencias de una persona [Gauch, et al., 2007]. Las habilidades de un colaborador (claseSkill) se refieren a las capacidades necesarias para llevar a cabo un conjunto de actividadescon un cierto nivel de certeza (atributo dexterityLevel). El rol de un colaborador (claseRole) esta definido por un conjunto de 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 por los estados (atributo state) presente o ausente, pero si el colaborador esta presente,el puede estar ocupado, accesible, contactable si es posible y disponible. Un colaborador puedemostrar simultaneamente diferentes niveles de disponibilidad a sus colegas dependiendo (cf.Mecanismo de disponibilidad en la seccion 5.2.2) de:

Capıtulo 5 127

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

Componente propuesto en el dominio de los sistemas mono-usuario

Extensión propuesta en esta tesis

Componente propuesto en el dominio de los sistemas colaborativos

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

RichDesktop

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


• la similitud (atributo similarity) entre su actividad actual y las actividades en curso opotenciales de los colaboradores que perciben su estado de disponibilidad;

• la fecha lımite (atributo timeSlot) de su actividad actual.

Como se muestra en la Figura 5.1, una actividad (clase Activity) es un conjunto de accionescoherentes (clase Action) sobre un objeto compartido (clase SharedObject) o privado (clasePrivateObject) que tienen un objetivo comun (atributo goal). La similitud de actividades esmedida en terminos de los objetos compartidos que estan siendo manipulado por los colabo-radores y de sus actividades actuales o potenciales (atributo sortActivity). La similitud entrelas actividades de dos colaboradores puede tomar alguno de los siguientes valores: muy similar,similar, mas o menos similar, poco similar, muy poco similar y no similar (cf. Mecanismo desimilitud 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 por sus colegas en un momento dado, e.g.,video-conferencia, mensajerıa instantanea, correo electronico o voz IP. Ası, cada colaboradorpuede ser contactado por varios medios de comunicacion dependiendo de:

1. el hardware y el software (clases Hardware y Software) disponible en sus dispositivosactuales (clase ComputerDevice) i.e., los que esta utilizando para lograr su actividad encurso, y

2. su estado de disponibilidad (atributo state de la clase Availability) o la similitudentre su actividad actual y las actividades en curso o potenciales de los colaboradores quequieren contactarlo (relacion hasSimilarity de la clase Activity).

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 ofreceinterfaces de usuario (clase UserInterface) para interactuar con sus colegas. Ademas, dicho es-pacio proporciona una area de trabajo privada (clase PrivateWorkspace), donde el colaboradorrealiza sus aportaciones personales (clase PrivateObject). Tambien, dicho colaborador puedecompartir con su grupo de colegas un espacio comun (clase SharedWorkspace), donde cadauno publica sus contribuciones. Dicho espacio de trabajo comun provee consciencia de grupo(clase GroupAwareness) por medio de una barra de colaboradores (clase CollaboratorBar).Dependiendo del rol actual del colaborador, su desktop (clase RichDesktop) provee aplica-ciones colaborativas que facilitan las actividades correspondientes a su rol (cf. Mecanismo paraocultar, 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 (clase

Capıtulo 5 129

SharedObject). Gracias al desktop, una aplicacion colaborativa puede estar relacionada conotras por medio de sus respectivos objetos compartidos (clase Link). Un objeto compartidoes implementado siguiendo el patron de diseno Composite porque el marco XARE pretendesoportar el dominio de aplicacion de edicion colaborativa de documentos.

Cada instancia de una aplicacion colaborativa es capaz de enviar notificaciones a otras in-stancias (clase Notification), con la finalidad de que los colaboradores posean la informacionnecesaria para realizar sus actividades (cf. Figura 5.1). Dichas notificaciones pueden ser en-viadas usando diferentes modalidades (clase Modality), e.g., sonido, vibracion o cuadros detexto, dependiendo tanto de la actividad en curso como de la ubicacion fısica del receptor. Lacomunicacion (clase Comunication) entre las instancias de una aplicacion les permite obtenerinformacion nueva o almacenada.

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. instantanea (clase ImmediateForm), la cual se refiere a transmitir la informacion en elmomento justo en que es generada, y

2. periodica (clase PeriodicForm), la cual notifica la informacion en momentos predefinidos.

El entorno comun (clase CommonEnvironment) es aquel donde toma lugar la colaboracion, lacual involucra diversas variables contextuales, e.g., los lugares fısicos (clase PhysicalPlace) endonde los colaboradores estan interactuando. Por lo tanto, tres configuraciones de trabajo sonposibles:

1. todos los colaboradores estan distribuidos, i.e., cada uno esta 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 co-localizados,mientras otros estan distribuidos.

Para determinar si el grupo de colaboradores esta distribuido y/o co-localizado, se debe de-tectar la presencia de los colaboradores en lugares especıficos (e.g., una sala de juntas) mediantehardware o software. La deteccion por hardware se hace por medio de sensores (clase Sensor),e.g., sensores infrarrojos. En cambio, la deteccion de colaboradores por software se lograr alusar aplicaciones dedicadas, e.g., reconocimiento de rostros.

La implantacion de un entorno multi-dispositivo y multi-usuario implica que cada colabo-rador puede no solo tener la posibilidad de interactuar con otros colaboradores, sino tambien


utilizar simultaneamente varios dispositivos para ejecutar sus actividades, e.g., cuando los co-laboradores estan co-localizados (clase ColacalizedSetting), cada colaborador puede teneruna computadora portatil (clase ComputerDevice), en donde su espacio de trabajo privado esdesplegado (clase PrivateWorkspace), y un telefono inteligente que actua como control remotode un pizarron electronico (clase SharedWorkspace), donde el espacio de trabajo compartidopuede 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. En este trabajo de investigacion se manejael concepto de “objeto abstracto” (clase AbstractObject) para referirnos a la informacionelectronica que es utilizada, generada y compartida por los colaboradores. La informacionelectronica se refiere a: audio (clase Audio), video (clase Video), imagenes (clase Image) ydocumentos de texto (clase Text), e.g., manuales, reportes, artıculos, ası como informaciongenerada desde la mensajerıa instantanea que se ejecuta en cualquier dispositivo de computo.

5.1.2 Componente observador

El componente contexto de uso (clase ContexOfUse) esta provisto de un componente observador(clase Watcher), el cual es responsable de observar los cambios contextuales con el fin deejecutar los percutores de adaptacion (clases Remodelation y Redistribution), definir tantola granularidad del estado de recuperacion (clase Recovery) como la granularidad de adaptacion(clase Adaptation) y detectar cuando se esta relacionando un objeto compartido con otro (claseLink) de manera implıcita o explicita (cf. Figura 5.2).

Varias de las clases que ejecuta la clase Watcher pueden ofrecer varios tipos de meta-interfaces de usuario (clase MetaUI), los cuales corresponden a: meta-IU con negociacion(metodo WithNegotiation()), meta-IU sin negociacion (metodo WithoutNegotiation()) ymeta-IU plastica (metodo Plastic()). Dichas meta-interfaces estan a cargo de informar loscambios que deben 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 interfaz de usuario de una aplicacion a diversosdispositivos de interaccion. Los tipos de redistribucion son los siguientes: 1) de centralizada acentralizada, 2) de centralizada a distribuida, 3) de distribuida a centralizada y 4) de distribuidaa distribuida”.

La clase Redistribution tiene como finalidad redistribuir la interfaz de usuario de una

Capıtulo 5 131

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 componente observador

aplicacion colaborativa en un conjunto de dispositivos, los cuales pueden pertenecer a un co-laborador (clase Collaborator) o un grupo de colaboradores (clases GroupOfCollaborators).La clase Watcher esta encargada de llamar a la clase Redistribution, cuando detecta cambiosen la configuracion del grupo y/o el ingreso o la salida de un dispositivo de computo.

Como se menciono en la seccion precedente, la configuracion del grupo se refiere a tres formasposibles de trabajo de los colaboradores: 1) co-localizada (clase ColocalizedSetting), 2)distribuida (clase DistribuitedSetting) e 3) hıbrida (clase HybridSetting). Para ejecutar elpercutor de redistribucion, la clase Watcher considera algunos cambios contextuales, los cualesson ejemplificados a continuacion:

• Suponga que un grupo de colaboradores trabaja en una sala de juntas, la cual estaequipada con algunos dispositivos de caracter publico, e.g., un pizarron electronico. Cadacolaborador dispone de un dispositivo movil, e.g., una tablet o un telefono inteligente.Al momento en que la clase Watcher detecta el conjunto de dispositivos en uso y laconfiguracion del grupo (en este caso, co-localizada), esta clase ejecuta el percutor deredistribucion (clase Redistribution) para que la interfaz de usuario de la aplicacion co-laborativa sea repartida entre dichos dispositivos, e.g., los colaboradores podrıan tener suespacio privado (clase PrivateSpace) en sus dispositivos moviles, mientras que el espaciocompartido (clase SharedWorkspace) podrıa ser desplegado en el pizarron electronico.


• Considere que el mismo grupo de colaboradores continua trabajando de manera co-localizada, pero uno de los integrante quiere utilizar dos dispositivos a la vez para in-teractuar con la aplicacion colaborativa. La clase Watcher detecta el ingreso del nuevodispositivo y, en consecuencia, ejecuta la redistribucion (clase Redistribution) de lainstancia de aplicacion de dicho colaborador. En este caso, la interfaz de usuario quemuestra su espacio de trabajo privado pasa de un estado centralizado a uno redistribuido.

• Posteriormente, todos los colaboradores salen de la sala de juntas para dirigirse a susrespectivas oficinas, ası que la clase Watcher detecta el cambio de configuracion grupal (deco-localizada a distribuida). En este caso, dicha clase ejecuta el percutor de redistribucion(clase Redistribution) para replicar el espacio de trabajo compartido, desplegado en elpizarron electronico, en los dispositivos moviles de los colaboradores. En consecuencia,la interfaz de usuario del espacio compartido cambia de un estado centralizado a unoreplicado, ya que cada colaborador tiene en su dispositivo movil tanto su espacio privadocomo el espacio compartido.

• Tiempo despues, algunos de los colaboradores deciden reunirse nuevamente en la sala dejuntas para discutir un topico en especıfico, ası que algunos continuan trabajando en susrespectivas oficinas, mientras otros trabajan cara a cara (configuracion hıbrida). En con-secuencia, la clase Watcher ejecuta el percutor de redistribucion (clase Redistribution)al momento de detectar este cambio en la configuracion del grupo. En este caso, la inter-faz de usuario de espacio de trabajo compartido se reconcentra en el pizarron electronico,ya que este es accessible a todos los colaboradores que estan co-localizados.

La forma de trabajo de un grupo no necesariamente debe partir de una configuracion co-localizada para despues pasar a una redistribuida y finalizar con una hıbrida, sino que la con-figuracion del grupo tambien puede empezar siendo redistribuida o hıbrida, para posteriormentepasar a alguna de las tres configuraciones mencionadas.

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 de la interfaz de usuario de una aplicacion que sea perceptibleal usuario. La reconfiguracion de la interfaz de usuario resulta de la aplicacion de una o mastransformaciones sobre todos o algunos de los componentes”.

La clase Remodelation permite ocultar, sustituir o agregar componentes en una interfaz deusuario. Los componentes susceptibles a remodelar son los siguientes (cf. seccion 4.2):

• el espacio de trabajo privado de un colaborador dependiendo su rol (clase Role), cuandoeste ingrese a su desktop;

• el espacio de trabajo compartido al detectar a un grupo de colaboradores tra-bajando co-localizadamente (clase ColocalizedSetting) o distribuidamente (claseDistribuitedSetting);

Capıtulo 5 133

• informacion, e.g., ocultar informacion restringida al detectar a una persona ajena al grupode colaboradores o mostrar informacion relevante dependiendo del lugar, del momento yde las necesidades del colaborador;

• los medios de contacto y la disponibilidad de un colaborador (clases Availability yContactMeans) dependiendo de los colaboradores implicados.

La clase Watcher ejecuta la clase Remodelation al detectar algunos de los siguientes cambioscontextuales:

• inicio de sesion por parte de un colaborador;

• identificacion de la configuracion del grupo (distribuida, co-localizada o hıbrida);

• deteccion de una persona, ajena al grupo de trabajo, que esta muy cerca del area dedespliegue de informacion;

• determinacion del momento en el que se debe enviar informacion relacionada con la ac-tividad de un colaborador;

• calculo de la disponibilidad un colaborador 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 que los usuarios deben realizar para continuar su actividad una vez finalizadoel proceso de adaptacion de un sistema interactivo. Dicha granularidad aborda tres niveles:sesion, tarea y accion fısica”.

La clase Recovery tiene como finalidad almacenar el estado de los espacios compartidos y pri-vados (clases SharedWorkspace y PrivateWorkspace, respectivamente), los cuales mantienenel trabajo en proceso. La clase Watcher ejecuta la clase Recovery antes y despues de llevar acabo la adaptacion al nuevo contexto de uso.

En la seccion 2.3 del capıtulo 2 se menciono que la granularidad de la adaptacion de loscomponentes de la interfaz 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 los percutores de remodelacion y/o redistribucion.

Finalmente, la clase Link tiene como objetivo relacionar una aplicacion con otra por mediode sus objetos compartidos. La clase Watcher ejecuta la clase Link cuando detecta que uncolaborador relaciona un objeto de una aplicacion con un objeto de otra aplicacion por mediode una hiperliga.


5.2 Mecanismos del marco XARE

El marco XARE ofrece a los desarrolladores varios mecanismos que realizan los calculos necesar-ios para llevar a cabo la adaptacion al contexto. Algunos de esos calculos se efectuan mediantereglas difusas.

5.2.1 Mecanismo de similitud de actividades

La similitud de actividades involucra a un colaborador observado y a un observador. Losparametros necesarios para calcular la similitud de actividades corresponden a: 1) las activi-dades potenciales y actuales que estan siendo realizadas por dichos colaboradores y 2) losobjetos compartidos que estan procesando mediante sus acciones.

El grado de similitud entre las actividades de los colaboradores observador y observado puedetomar los siguientes valores:

1. muy similares, cuando estan llevando a cabo las mismas acciones sobre el mismo objetocompartido;

2. similares, cuando estan ejecutando las mismas acciones en diferentes objetos relacionados(e.g., una figura y el correspondiente parrafo que describe esta);

3. mas o menos similares, cuando estan ejecutando las mismas acciones en diferentes objetosno relacionados (e.g., modificacion de diferentes secciones);

4. poco similares, cuando estan ejecutando diferentes acciones sobre el mismo objeto com-partido;

5. muy poco similares, cuando estan ejecutando diferentes acciones sobre diferentes objetosrelacionados;

6. no similares en cualquier otro caso.

En la tabla 5.1 se ejemplifica la forma de asignar los diferentes grados de similitud entrelas actividades del colaborador un y las de sus colegas u1, u2, u3, u4, u5 y u6. El mecanismotoma en cuenta las acciones actuales que estan llevando acabo estos colaboradores y los objetosque estan manipulando por medio de tales acciones. Dicho mecanismo tambien considera lasacciones y los objetos que son potencialmente accesibles al colaborador un. De esta forma,el colaborador un tiene actividades muy similares y similares a las de los colaboradores u1

y u2, respectivamente durante una sesion de trabajo donde los colaboradores u1 y un estanmodificando concurrentemente el objeto compartido o, mientras que el colaborador u2 estamodificado el objeto compartido p, el cual esta relacionado con el objeto o.

Capıtulo 5 135

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-ciones sobre el objeto o

Poco similaresPotencialmente mas omenos similares

u5 esta leyendo el objeto p Muy poco similaresPotencialmente no simi-lares

u6 esta leyendo el objeto q No similaresPotencialmente pocosimilares

Tabla 5.1: Similitud entre las actividades de dos colaboradores

Sin embargo, la situacion previamente descrita puede ser completamente diferente en unasesion subsecuente o incluso en la misma sesion, debido al caracter dinamico del trabajo colab-orativo. 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 mismas actividades mencionadas, la actividad del colaborador un no essimilar a las de los colaboradores u1 y u2.

Las clases utilizadas por este mecanismo son Activity y Action. La primera clase permiteobtener el conjunto de actividades asociadas a ambos colaboradores (observado y observador) ycalcular la similitud de actividades mediante el metodo HasSimilarity. Por su parte, la claseAction permite identificar sobre que objeto compartido estan trabajando dichos colaboradoresen un momento dado para inferir la actividad en curso. Este mecanismo es requerido por losmecanismos de disponibilidad y de medios de contacto para llevar a cabo sus propios calculos.


5.2.2 Mecanismo de disponibilidad de un colaborador

Este mecanismo es responsable de determinar la disponibilidad de un colaborador observado,cuyo valor varıa de un observador a otro. El colaborador observado puede ser percibido comopresente o ausente durante una sesion de trabajo y, en caso de que este presente, el observadorpuede percibir subestados, cuyo objetivo es proveer mas detalle acerca de la disponibilidad delcolaborador observado. Ası, cuatro subestados son considerados por este mecanismo:

1. ocupado: posibilita al colaborador observado de informar que no quiere ser interrumpido;

2. accesible: permite al colaborador observado indicar que, aun si esta ocupado, puede serinterrumpido si es necesario y tan pronto como pueda respondera;

3. contactable si es posible: el colaborador observado admite que puede ser inte-rrumpido, pero no asegura una rapida respuesta;

4. disponible: permite al colaborador observado indicar que puede ser contactado encualquier momento.

Al igual que la similitud de actividades, la disponibilidad se calcula tomando en cuenta lasiguiente informacion del colaborador observado y del observador:

1. la similitud entre la actividad en curso del colaborador observado y las actividades po-tenciales y actuales del observador y

2. la fecha lımite de la actividad en curso (e.g., distante o cercana) del colaborador observado.

En caso de que la disponibilidad haya sido establecida manualmente por el colaborador obser-vado, este mecanismo tiene que considerar las preferencias establecidas por el.

La tabla 5.2 muestra algunos ejemplos de los subestados de disponibilidad de un colaboradorobservado, tal como estos son percibidos por un observador de acuerdo a las condiciones previas.Cuando el colaborador observado y el observador estan ejecutando actividades muy similareso similares, el observador puede percibir la disponibilidad del colaborador observado comoaccesible, sin importar si la fecha lımite de la actividad de este ultimo es cercana o distante.En esta situacion, el mecanismo favorece la posibilidad de mantenerse contactable por personasrelacionadas por la similitud de sus actividades.

Por otro lado, si los colaboradores estan ejecutando actividades mas o menos similares opoco similares, el observador puede percibir la disponibilidad del colaborador observado comocontactable si es posible, cuando la fecha lımite de la actividad de este ultimo sea cercana,o accesible, cuando dicha fecha sea distante. En el caso de que dichos colaboradores estenejecutando actividades muy poco similares o diferentes, pero una de las actividades potencialesdel observador es muy similar o similar a la actividad actual del colaborador observado, el

Capıtulo 5 137

Disponibilidad del colaborador observado Fecha lımite

Cercana ... 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

Contactablesi 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



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

OcupadoContactablesi es posi-ble

Las actividades actuales y potenciales del observador sonmuy poco similares o no son similares a la activi-dad actual del colaborador observado

Ocupado Ocupado

Tabla 5.2: Estados de disponibilidad de un colaborador percibidos por sus colegas

observador percibira la disponibilidad del colaborador observado como contactable si es

posible, sin importar cuando termina la actividad de este ultimo. En estas situaciones, elmecanismo facilita el contacto entre los colaboradores, aunque en diferentes grados, ya que laprobabilidad de estar relacionados en un momento dado es alta.

Cuando las actividades en curso tanto del colaborador observado como del observador sonmuy poco similares o no similares, pero sus actividades serıan mas o menos similares o pocosimilares en un momento dado, el mecanismo solo facilita el contacto cuando la fecha lımite dela actividad del colaborador observado es distante. De otra manera, el observador percibira alcolaborador observado como ocupado. Finalmente, si los colaboradores implicados no tienenen comun actividades actuales ni potenciales, el contacto no es posible. Sin embargo, estemecanismo puede ser configurado por cada colaborador, con el fin de proveer opciones masflexibles. Por ejemplo, este mecanismo puede permitir 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 estos colaboradores estan trabajando en el mismo proyecto.


Aun si los subestados de disponibilidad estan determinados por el mecanismo propuesto, elcolaborador observado puede modificarlos cuando lo requiera.

Este mecanismo usa las clases Availability y Activity. En particular, este mecanismoforma parte de la primera clase, Availability. La clase Activity proporciona la similitudentre las actividades de los colaboradores involucrados, ası como la fecha lımite de la actividaden curso del colaborador observado (cf. atributo timeSlot de la clase Availability de laFigura 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 colabo-rador tiene la libertad de determinar su preferencia por algunos medios de contacto, el marcoXARE propone un mecanismo para establecer dichos medios de manera automatica. Comose muestra en la Figura 5.3, este mecanismo hace uso de los mecanismos descritos en lasdos subsecciones 5.2.1 y 5.2.2. Nuevamente, debemos hacer la distincion entre colaboradorobservado y observador, dado que uno de estos mecanismos requiere de esta diferenciacion.

El primer mecanismo esta a cargo de determinar la similitud entre las actividades en curso dedos colaboradores. Este mecanismo toma, como parametros de entrada, la actividad en cursode cada colaborador (cf. actividad a y actividad b de la Figura 5.3), la cual esta definida porla accion que cada colaborador esta ejecutando (cf. accion a y accion b de la Figura 5.3) y elobjeto que esta siendo manipulado por dicha accion (cf. objeto a y objeto b de la Figura 5.3).Como se menciono en la seccion 5.2.1, este mecanismo da como resultado un valor difuso desimilitud (e.g., muy similar, mas o menos similar o no similar).

El segundo mecanismo es responsable de determinar la disponibilidad de un colaborador,cuyo valor varıa de un observador a otro, dependiendo de la similitud entre las actividades encurso del colaborador observado y del observador, ası como de la fecha lımite de la actividad delprimero. El parametro de entrada correspondiente a la fecha lımite de la actividad es tambienun valor difuso (e.g., cercana o distante). Como resultado, este mecanismo crea un objeto dela clase Availability, el cual esta relacionado con un objeto de la clase Collaborator querepresenta al colaborador observado. Como se menciono en la seccion 5.2.2, la disponibilidad deun colaborador es tambien un valor difuso (e.g., ocupado, contactable si es posible o accesible).

Con base en estos dos mecanismos previamente mencionados, el marco XARE propone unmecanismo que permite a los colaboradores definir sus medios de contacto. Este mecanismoacepta diversos conjuntos de parametros de entrada, aunque un parametro comun de todos estosconjuntos se refiere a las caracterısticas de software y hardware de los dispositivos utilizados porlos colaboradores implicados en un proceso de comunicacion. Por lo tanto, cada colaboradorpuede configurar su propia instancia de este mecanismo con base en los siguientes parametrosde entrada:

Capıtulo 5 139

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

similitud

(observado y

observador)

similit

ud

(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

Acción:acción_b

Mecanismo:Disponibilidad

Mecanismo: Similitud

Mecanismo:

Medio de contacto

Figura 5.3: Mecanismo para determinar los medios de contacto de un colaborador

1. los subestados de disponibilidad del colaborador;

2. la similitud entre las actividades del colaborador y las de sus colegas;

3. los medios de contacto preferidos del colaborador;

4. la proximidad logica entre el colaborador y sus colegas en el espacio de trabajo compartidode una aplicacion colaborativa (cf. seccion 5.2.6).

La salida de este mecanismo es la creacion de un objeto de la clase ContactMeans quecontiene una lista de los medios de contacto asociados al colaborador observado, quien estarepresentado por un objeto de la clase Collaborator. La lista resultante de medios de contacto


sera visualizada por un observador dado. Por cada uno de los medios de contacto de esta lista,el mecanismo asegura que los dispositivos de los colaboradores involucrados cuentan con lascaracterısticas de software y hardware necesarias para establecer la comunicacion entre ellos(clases Hardware y Software).

5.2.4 Mecanismo de ocultar, sustituir y mostrar componentes

El mecanismo para ocultar, sustituir y mostrar componentes en una interfaz de usuario tienecomo objetivo modificar la visibilidad de dichos componentes dependiendo de algunos factores,e.g., dependiendo del rol del colaborador, solo se muestran los iconos de acceso directo a lasaplicaciones utiles a dicho rol o en funcion del espacio libre en el disco local de un dispositivo sepuede almacenar la informacion local o remotamente. Este mecanismo (cf. Figura 5.4) aceptados parametros de entrada:

1. el rol de un colaborador, y

2. el conjunto de dispositivos disponibles, los cuales se refieren a aquellos que pertenecen alos colaboradores participantes en una sesion y servidores.

Para explicar mejor el mecanismo esquematizado en la Figura 5.4, supongamos que el usuariocolaborador a juega el papel de rol a e ingresa a su escritorio desktop a mediante la computa-dora dispositivo a. Este mecanismo debe mostrar al colaborador a solo los componentes (e.g.,aplicacion a) que son adecuados para desempenar el rol a utilizando el dispositivo a. En elcaso de componentes que representan una funcionalidad, e.g., ıcono de guardar o imprimir, severifica si el dispositivo a puede ofrecer directamente dicha funcionalidad o requiere la ayudade otros dispositivos, e.g., el dispositivo b, los cuales podrıan no pertenecer al colaborador a.Deduciendo del ejemplo anterior, las principales clases involucradas en este mecanismo son:Role, ComputerDevice y Desktop. Mediante la clase Role es posible obtener el rol actual deun colaborador, el cual esta representado por un objeto de la clase Collaborator. La claseComputerDevice esta relacionada con las clases Collaborator, Hardware y Software con el finde proporcionar las caracterısticas de hardware y software de los dispositivos en uso de un co-laborador y ademas, cuando sea necesario. La clase ComputerDevice ofrecera las caracterısticasde otros dispositivos disponibles que pueda utilizar dicho colaborador. La clase Desktop ponea disponibilidad del colaborador en cuestion aquellas aplicaciones colaborativas (representadaspor objetos de la clase AplicacionColaborativa) que son utiles para el rol actual del colabo-rador. Aunque no se ilustra en la Figura 5.4, este mecanismo tambien pueden modificar algunasfuncionalidades especıficas de las aplicaciones disponibles al colaborador, e.g., algunos de losiconos ofrecidos por una aplicacion pueden ser ocultados por no estar relacionados al rol actualdel colaborador.

Capıtulo 5 141

ConjuntoDePlataformas

EntornoComún


tieneColaborador:colaborador_a

Rol:rol_a

tiene

tiene

tiene

tiene tiene

tiene

tiene

modificarComponente()

modificarComponente()

rolActual

Mecanismo:Ocultar/Mostrar

RichDesktop:desktop_a

AplicaciónColaborativa:aplicaciónColaborativa_a

Hardware:hardware

Sofware:software

Dispositivo:dispositivo_a

Dispositivo:dispositivo_b

Dispositivosopcionales

Dispositivos personales

Figura 5.4: Mecanismo para ocultar, sustituir o mostrar componentes y/o funcionalidades

5.2.5 Mecanismo para la creacion de referencias deıcticas

Este mecanismo permite a los colaboradores crear referencias deıticas desde una aplicacionhacia los objetos compartidos de otra aplicacion, con la finalidad de mantener el contexto dedichos objetos. La funcionalidad de deixis (cf. Figura 5.5) ofrecida por este mecanismo generacomo resultado ligas de hipertexto entre una palabra clave de la mensajerıa instantanea y unobjeto compartido del editor colaborativo. Gracias a esta funcionalidad, los colaboradores nonecesitan copiar objetos desde el editor colaborativo hacia la mensajerıa instantanea cuandoen el curso de una conversacion se hace referencia a ellos.

El mecanismo de referencias deıticas recibe dos parametros de entrada por parte de uncolaborador:

1. palabras deıcticas, tales como esta figura, la siguiente seccion, este parrafo, esas referen-cias bibliograficas o aquı, las cuales son seleccionadas desde la mensajerıa instantanea;



EntornoComún

tiene

tiene

tiene

tiene

tiene

palabra deítica

tiene

tiene

tiene

párrafo

tieneMecanismo:

Deixis

Colaborador:colaborador_a

RichDesktop:desktop_a

AplicaciónColaborativa:mensajeríaInstantánea

ObjetoCompartido:palabraDeíctica

ObjetoCompartido:párrafo

ReferenciaDeítica:referenciaDeíctica

AplicaciónColaborativa:editorColaborativo

Rol:rol_a

Figura 5.5: Mecanismo de referencias deıticas

2. un objeto compartido como un tıtulo, un parrafo, una frase, una palabra, una referen-cia bibliografica, una figura o una seccion; dicho objeto es seleccionado desde el editorcolaborativo.

En la Figura 5.5 se puede observar al usuario colaborador a, quien trabaja en su escrito-rio desktop a en donde esta usando las aplicaciones mensajerıaInstantanea y editorColabo-rativo. En este caso, dicho colaborador crea una referencia deıctica entre una palabra clavepalabraDeıctica y un objeto compartido parrafo.

Cuando el colaborador de clic sobre la referencia deıctica de la mensajerıa instantanea, sedebe mostrar el objeto referenciado a la mitad del area de despliegue del editor colaborativo.En caso de que el objeto referenciado sea un texto, este debe cambiar de color para ser re-saltado; en cambio, si el objeto referenciado es una imagen, esta debe ser puesta en evidenciamediante un recuadro coloreado. Ademas, el escritorio debe ofrecer la opcion de crear unareplica en el pizarron multi-usuario de la imagen referenciada en el editor colaborativo. Elescritorio mantiene un identificador y la ubicacion de la imagen dentro del documento origen.

Capıtulo 5 143

Las modificaciones realizadas desde el pizarron seran reflejadas automaticamente en el editorde texto.

Las principales clases involucradas en este mecanismo son Link y SharedObject. Un ob-jeto de la clase Link mantiene la referencia deıtica, mientras que dos objetos de la claseSharedObject representan una palabra deıtica y un objeto referenciado.

5.2.6 Mecanismo de proximidad logica

La proximidad logica entre dos colaboradores es medida en terminos de la relativa cercanıaentre los objetos compartidos que estan manipulando dichos colaboradores en el espacio detrabajo compartido de una aplicacion colaborativa. Con el fin de facilitar la explicacion de estemecanismo, supongamos que durante una sesion de trabajo, los colaboradores mencionadosestan modificando, visualizando y/o anotando objetos compartidos que siguen una estructurade arbol, e.g., un documento de texto o de imagenes (cf. Figura 5.6), cuyo nodo raız es elnombre del documento (el contenedor de texto e imagenes) o del proyecto (el contenedor deimagenes) en cuestion.

En la Figura 5.6a, se puede observar que la granularidad de objetos en un documento detexto va desde el documento completo hasta la palabra. La estructura de dicha figura muestraun documento de texto, cuyo nombre es Di, el cual tiene secciones (S) que pueden contenerparrafos (P ), imagenes (I) o subsecciones (U). A su vez, dichas subsecciones tambien puedencontener parrafos e imagenes. Los parrafos se componen de palabras (A).

En el caso de las imagenes, la granularidad va desde el nivel de proyecto hasta nivel defiguras, las cuales puede ser una lınea, un cırculo, un rectangulo y un cuadrado. La Figura5.6bmuestra un proyecto de imagenes vectoriales, cuyo nombre es (Pi), el cual contiene hojas (H)que sirven de lienzos de dibujo. Dichas hojas contienen imagenes (I) que estan compuestas porfiguras (F ) basicas.

Para definir los grados de proximidad logica en el espacio de trabajo compartido, este mecan-ismo usa valores de granularidad gruesa con la finalidad de determinar que dichos colaboradoresestan:

1. muy cercanos, cuando estan accediendo al mismo objeto compartido, sin importar surespectivo tipo de acceso (e.g., leer, escribir o anotar);

2. mas o menos cercanos, cuando estan manipulando diferentes objetos compartidos (e.g.,subsecciones), los cuales tienen el mismo padre (e.g., una seccion);

3. 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 ejemplo, consideramos los objetos actuales que dichos colabo-


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

radores estan accediendo y los objetos potenciales que estan al alcance del colaborador un.Tanto los objetos en curso como los objetos potenciales pueden ser determinados a partir delas actividades actuales y potenciales de los colaboradores, respectivamente. Ası, aunque loscolaboradores un y u3 pueden estar distantes uno del otro en el espacio de trabajo compartido,cuando esten manipulando los objetos o y q respectivamente, la posibilidad de acceder a otrosobjetos compartidos (e.g., un puede tambien manipular q) permite al colaborador un estar po-tencialmente muy cerca del colaborador u3 en el espacio de trabajo compartido, pero lejos delos colaboradores u1 y u2.

Las principales clases involucradas en este mecanismo son AbstractObject, Activity,Action y SharedObject. Objetos de la clase SharedObject representan los objetos com-partidos, los cuales sirven de base para calcular los grados de proximidad logica. Un objeto

Capıtulo 5 145

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 cerca Potencialmente remoto

Objeto actual p del compo-nente c de u2, tal que p 6= o,

Mas o menos cerca Potencialmente remoto

Objeto actual q del compo-nente d de u3, tal que d 6= c,

RemotoPotencialmente muycerca

Tabla 5.3: Proximidad logica entre dos colaboradores en un espacio de trabajo compartido

de la clase AbstractObject permite crear la estructura de arbol para los documentos de textoy de imagenes. Finalmente, objetos de la clase Activity denotan a los objetos potenciales,mientras que objetos de la clase Action representan al objeto actual. Estas dos ultimas clasesestan asociadas por supuesto a un objeto de la clase Collaborator.

5.2.7 Mecanismo ubicacion fısica

Este mecanismo se encarga de determinar si los integrantes de un grupo se encuentran traba-jando en el mismo lugar fısico y al mismo tiempo (ver Figura 5.7). Los parametros requeridospor este mecanismo son: el tiempo y la ubicacion de cada colaborador.

• El tiempo es empleado para registrar el momento en que entra y sale cada colaboradorde un lugar especıfico.

• La ubicacion es el lugar fısico donde se encuentra el colaborador.

Ambos parametros se obtienen a traves del dispositivo movil de cada colaborador. Unaopcion a utilizar para obtener la ubicacion de los colaboradores mediante hardware es usandola tecnologıa de comunicacion inalambrica NFC (Near Field Communication)1. En la entradade cada habitacion se coloca una etiqueta NFC que representa al lugar fısico. Al momento enque un colaborador llega al lugar y lee, mediante su dispositivo movil, la etiqueta asociada almismo, se registra su presencia en ese lugar y la hora en que ingreso.

Dado que la ubicacion de un colaborador se conoce cuando se lee la etiqueta NFC asociadaa la habitacion, no es posible realizar el seguimiento de su posicion dentro de ese lugar fısico.

1NFC Forum, NFC Forum Technical Specifications, http://www.nfc-forum.org/specs/spec_list/, 2004

http://www.nfc-forum.org/specs/spec_list/


EntornoComún

Colaborador:colaborador_a

Colaborador:colaborador_b

ubicación/horaEgreso

ubicación/horaEgreso

Notificar resultadoa otros componentes

Mecanismo:UbicaciónFísica

Figura 5.7: Mecanismo de ubicacion fısica

Por lo tanto, esta informacion tiene que ser almacenada en una base de datos al momento enque el colaborador ingrese al lugar.

Dados dos colaboradores identificados como 1 y 2, el mecanismo propuesto comprueba si laubicacion del colaborador 1 es igual a la ubicacion del colaborador 2 y si el tiempo de egresode los colaboradores no ha sido registrado. Si ambas condiciones son afirmativas, entonces sededuce que ambos colaboradores se encuentran co-localizados.

Se decidio emplear la tecnologıa NFC debido a que esta siendo incluida en la mayorıa delos dispositivos moviles nuevos, por lo tanto no tenemos que incorporar hardware externoal dispositivo. Ademas, se hace uso de etiquetas NFC, las cuales son de bajo costo. Asımismo, se espera que para el ano 2014 uno de cada cinco dispositivos moviles cuenten condicha tecnologıa2. Estas razones hacen que la implementacion de este mecanismo sea rentabley factible.

Se podrıa utilizar otras tecnologıas de comunicacion para obtener la ubicacion fısica, e.g.,sensores infrarrojos o sensores de Identificacion por Radio-Frecuencia (RFID). Asimismo, sepodrıa implementar algun mecanismo por software, e.g., deteccion de rostros.

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.

El marco propuesto se compone de tres capas: deteccion, adaptacion y espacio de trabajo. Lacapa de deteccion, que se encuentra en la parte inferior del marco, es responsable de reconocer

2Juniper Research, 1 in 5 Smartphones will have NFC by 2014,http://www.juniperresearch.com/viewpressrelease.php?pr=239, 2004

http://www.juniperresearch.com/viewpressrelease.php?pr=239

Capıtulo 5 147

cambios en las variables contextuales por medio de perceptores logicos y fısicos. La capa deadaptacion esta localizada entre las capas superior e inferior del marco XARE.

Esta capa intermedia esta a cargo de analizar la informacion obtenida por la capa de deteccionpara determinar si los nuevos cambios en el contexto de uso requieren o no la adaptacion delos espacios de trabajo publicos o privados de una aplicacion colaborativa. Cuando la capa deadaptacion considere que algun tipo de adaptacion es necesario, esta capa informa a la capa deespacio de trabajo como debe ser implementada dicha adaptacion (cf. Figura 5.8).

Esta ultima capa mencionada es la capa superior del marco XARE y es responsable de llevara cabo las modificaciones solicitadas por la capa de adaptacion.

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

La capa de deteccion se compone de dos tipos de perceptores (cf. Figura 5.8):

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 cadacolaborador donde se ejecutan aplicaciones colaborativas. Mediante esta variable esposible obtener las caracterısticas de hardware y software de estos dispositivos paraadaptar las aplicaciones colaborativas al componente conjunto de plataformas delcontexto de uso.

• Variable disponibilidad: denota la disponibilidad de cada colaborador, la cual puedeser definida manualmente por el propio colaborador o de manera automatica al serinferida por una aplicacion colaborativa (cf. seccion 5.2.2). Como se menciono enla seccion 5.1, esta variable puede tomar los valores presente o ausente, pero si elcolaborador esta presente, el puede estar ocupado, accesible o contactable si es posible.

• Variable actividad actual: representa la actividad en curso de cada colaborador, lacual puede ser inferida automaticamente por una aplicacion colaborativa a partir delas acciones ejecutadas por el colaborador sobre los objetos compartidos.

• Variable proximidad logica: denota la cercanıa entre un colaborador y sus colegas enel espacio de trabajo compartido de una aplicacion colaborativa (cf. seccion 5.2.6).

2. Perceptores fısicos: son principalmente sensores capaces de reconocer cambios en la sigu-ientes variables contextuales fısicas:

• Variable configuracion de un grupo: por medio de sensores RFID (Radio FrequencyIDentification) y de tecnologıa Bluetooth, es posible descubrir la entrada y salidade un colaborador en un lugar especıfico, con el fin de determinar si un grupo estacolaborando de manera co-localizada o distribuida.

• Variable proximidad fısica: denota la cercanıa entre los dispositivos de un colabo-rador y los de sus colegas. Por medio de esta variable es posible que dos colaboradoresacoplen sus tablets para crear un espacio de trabajo compartido a partir de dosespacios privados, como en Connectables [Tandler et al., 2001], o extender un espaciode trabajo compartido existente.

La capa de adaptacion esta compuesta de los siguientes modulos (cf. Figura 5.8):

1. Reglas de adaptacion: con base en los cambios detectados en el contexto de uso, estemodulo analiza si la aplicacion colaborativa en cuestion necesita ser adaptada o no. Encaso de que la adaptacion sea requerida, este modulo tambien especifica el tipo de tecnicasnecesarias para adaptar dicha aplicacion, ası como las granularidades de adaptacion yrecuperacion de estado.

2. Medios de adaptacion: se refiere a los resultados del proceso de adaptacion tales comoson percibidos por los colaboradores en la Interfaz de Usuario (IU). Ası, el proceso deadaptacion puede utilizar una o varias de las siguientes tecnicas:

• Redistribucion: consiste en reorganizar los componentes de la IU en diversos dis-positivos de interaccion. Cuatro tipos de redistribucion han sido identificados

Capıtulo 5 149

[Calvary et al., 2006]: a) de centralizada a centralizada, cuyo objetivo es conservarel estado centralizado de la IU, e.g., migracion de una PC a una PDA; b) de centra-lizada a distribuida, la cual desmiembra la IU en varias plataformas, e.g., reparticionentre una PC y una PDA; c) de distribuida a centralizada, cuyo efecto es reconcen-trar la IU en una sola plataforma; y d) de distribuida a distribuida, la cual modificael estado de distribucion de la IU.

• Remodelacion: involucra la reconfiguracion de la IU por medio de inserciones, supre-siones, substituciones y reorganizacion de todos o algunos componentes de la IU.Las transformaciones aplican a diferentes niveles de abstraccion: intra-modal, inter-modal y multi-modal. La remodelacion intra-modal ocurre cuando los componentesfuentes son redefinidos dentro de la misma modalidad, e.g., de una interaccion graficaa otra grafica. La remodelacion inter-modal redefine una modalidad diferente, ya quelos componentes de la IU sujetos a remodelacion se ven afectados al perder o au-mentar una modalidad. Ası, una IU multi-modal puede ser convertida en una IUmono-modal o de manera inversa. Finalmente, la remodelacion multi-modal permitela combinacion de transformaciones intra- e ınter- modales.

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 que la IU completa se ve afectadapor modificaciones; b) espacio de trabajo, el cual se refiere a un espacio que apoya laejecucion de un conjunto de tareas logicamente relacionadas, e.g., una ventana de im-presion; 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 que cualquiercomponente de la IU que puede ser dividido en multiples superficies; sin embargo, estegrano de adaptacion solo concierne a la tecnica de redistribucion.

4. Granularidad de recuperacion del estado: representa el esfuerzo que los usuarios debenrealizar para continuar con el desarrollo de su actividad, una vez finalizada la adaptacionde la IU. Tres granos de recuperacion son considerados [Vanderdonckt, et al., 2008]: a)nivel de sesion, el cual fuerza al usuario a reiniciar su sesion, perdiendo los efectos de todassus acciones ejecutadas; b) nivel de tarea, el cual asegura que todas las tareas terminadasson validadas de manera persistente, excepto la tarea interrumpida; y c) nivel de accionfısica, la cual asume que el usuario no pierde el efecto de ninguna accion.

La capa de espacio de trabajo esta compuesta de los siguientes modulos (cf. Figura 5.8):

1. Meta-interfaz de usuario (meta-IU): consiste en un conjunto de funciones, cuyo objetivo esevaluar y controlar el estado de una aplicacion colaborativa adaptativa. Coutaz y Calvaryidentifican tres tipos de meta-interfaz de usuario [Coutaz and Calvary, 2008]: a) meta-IU sin negociacion, la cual permite observar el estado del proceso de adaptacion, perono permite que el usuario intervenga; meta-IU con negociacion, la cual es recomendablecuando la meta-IU no puede tomar decisiones entre multiples formas de adaptacion, o


cuando el usuario debe controlar el resultado del proceso; y c) meta-IU plastica, la cualesta disenada para instanciar 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: denota el espacio comun donde los miembros de un grupocooperan por hacer sus contribuciones perceptibles por todos los miembros, cuando laestratificacion no existe, o por algunos miembros de otra manera.

El soporte de almacenamiento del marco XARE esta compuesto de dos repositorios (cf.Figura 5.8):

1. El repositorio de informacion contextual administra y almacena principalmente 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 basede datos esta encargada de almacenar dicha informacion.

2. Para dispositivos con poca capacidad de almacenamiento, el repositorio de interfaces deusuario almacena y administra informacion necesaria para desplegar las interfaces deusuario (e.g., diferentes vistas de interactores y espacios de trabajo, frecuencia de uso dealgunos interactores) y la recuperacion del estado (e.g., todas las acciones ejecutadas otareas terminadas).

5.4 Sıntesis

El marco XARE pretende servir como referencia para crear aplicaciones colaborativas adapta-tivas, dado que pone en evidencia las dependencias que existen entre las clases de dicho marcoy los componentes del contexto de uso. El marco propuesto sirve de base para implementar lamayorıa de las aplicaciones identificadas en el capıtulo 4.

En la tabla 5.4 se hace referencia a los mecanismos que permiten implementar las aplica-ciones identificadas en cuatro de los ocho escenarios descritos en el capıtulo 4. El escenario“mejoramiento del trabajo colaborativo”, el cual se refiere a asociar objetos de aplicacionesdiferentes, con el fin de mantener en todo momento el contexto de dichos objetos, puede serimplementado utilizando el mecanismo de “creacion de referencias deıcticas”.

El escenario “remodelacion de la interfaz de usuario”, el cual permite la modificacion decomponentes mediante ocultacion, agregacion o sustitucion, puede ser implementado medianteel “mecanismo de ocultar, sustituir y mostrar componentes”. Dicho mecanismo permite adaptarlos componentes dependiendo del rol y del conjunto de dispositivos en uso de cada uno de los

Capıtulo 5 151

Escenarios Mecanismos

1. Mejoramiento del trabajo co-laborativo

5.2.5. Creacion de referencia deıcticas

2. Remodelacion de la interfaz deusuario

5.2.4. Ocultar, sustituir o mostrarcomponentes

3. Redistribucion de una apli-cacion colaborativa

5.2.7. Ubicacion fısica y5.2.6. Proximidad logica

4. Mejoramiento de la concienciagrupal

5.2.1. Similitud de actividades,5.2.2. Disponibilidad de un colabo-rador5.2.3. Medio de contacto

Tabla 5.4: Sugerencias de mecanismos para implementar las aplicaciones de algunos escenariosanalizados

colaboradores. Este mecanismo puede usarse para ocultar los ıconos no relacionados con losroles, cuando la pantalla del dispositivo en uso tenga una baja resolucion o sea de tamano muypequeno. Ademas, las aplicaciones pueden optar por calcular la remodelacion de la IU en casode que el dispositivo soporte dicho calculo o por usar un servidor para que este les proporcionela IU, considerando las caracterısticas del contexto actual (dispositivo y colaboradores).

El escenario “redistribucion de una aplicacion colaborativa” permite adaptar componentesdado el tipo de interacciones (co-localizadas, distribuidas o hıbridas) puede llevarse acabo uti-lizando los dos mecanismos siguientes: 1) “proximidad logica” permite identificar si el grupode colaboradores se encuentra trabajando en la misma tarea; y, 2) “ubicacion fısica” permitedetectar cuando un grupo esta trabajando en un mismo lugar fısico o a distancia.

El escenario “mejoramiento del trabajo colaborativo” permite adaptar los medios de con-tacto y disponibilidad de los colaboradores; este escenario puede llevarse acabo al usar lossiguientes tres mecanismos: 1) “similitud de actividades” permite determinar la similitud delas actividades de dos colaboradores, 2) “disponibilidad de un colaborador” permite calcular ladisponibilidad del colaborador al usar la similitud de las actividades del usuario a contactar yel 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 imple-mentados usando los mecanismos existentes. Estos escenarios corresponden a: “suministro deinformacion relevante” (cf. seccion 4.8) y “Notificaciones multi-modales” (cf. seccion 4.9).


El escenario “suministro de informacion relevante”, que tiene como objetivo proveer infor-macion dado un contexto determinado, puede implementarse casi por completo al usar los sigu-ientes mecanismos: 1) “ocultar, sustituir y mostrar componentes” puede usarse para proveerinformacion necesaria dado el rol del colaborador y el dispositivo en uso, 2) “proximidad logica”nos 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) “similitud de actividades” permite de-tectar la similitud de actividades entre dos colaboradores, dicho mecanismo permitira ofrecerinformacion entre colaboradores dada sus actividades actuales o potenciales.

El escenario “Notificaciones multi-modales” tiene como objetivo notificar usando diferentesmodalidades. Este escenario se puede implementar parcialmente al usar los siguientes dosmecanismos: 1) “proximidad logica” para conocer en donde se encuentra el colaborador y asıdeterminar si esta solo o acompanado, y 2) “similitud de actividades” para determinar si laactividad del colaborador que genera la actividad esta relacionada con la actividad del quepotencialmente recibira dicha notificacion.

Capıtulo 6

Funcionamiento del marco XARE

El marco XARE esta compuesto principalmente por tres capas, las cuales se encargan dedetectar el entorno interno y externo del sistema, de adaptarse a los nuevos cambios e interactuarcon el colaborador. Ademas dicho marco requiere de dos bases de datos para almacenar diferentetipo de informacion relacionada con los colaboradores y el propio sistema.

En la seccion 6.1 se muestra las instancias del marco XARE en diferentes dispositivos, asıcomo la manera de comunicarse entre las instancias de dicho marco.

En la seccion 6.2 permite conocer la API por cada capa. Finalmente, en la seccion 6.3 sepresenta una sıntesis de este capıtulo.

6.1 Instancias del marco XARE

Las capas del marco XARE pueden estar instanciadas en los dispositivos huespedes, mas aun siestos dispositivos tienen suficientes capacidades, e.g., una computadora portatil, para almacenary procesar, pero muchos de los dispositivos no tienen la suficiente capacidad para instanciarcompletamente el marco, por lo que estos podrıan necesitar una entidad externa, e.g., unservidor. Supongamos una tablet, la cual podrıa almacenar la capa de espacio de trabajo, peroun telefono inteligente no, ası que ambos dispositivos podrıan requerir de una entidad externa(cf. Figura 6.1).

Para que la entidad externa adapte la interfaz de usuario del dispositivo huesped, este debeconsiderar las caracterısticas de hardware y software del dispositivo huesped, las cuales puedenser obtenidas de dos maneras:

1. el dispositivo huesped, e.g., un telefono inteligente, toman la iniciativa de informar ala entidad externa acerca de sus propias capacidades. Esta solucion es adecuada para

153

154 Funcionamiento del marco XARE

Servidor 1 Servidor N

Marco XARE

Marco XARE Marco XARE

Marco XARE

Espacio Trabajo

Espacio Trabajo Espacio Trabajo

Espacio Trabajo

Adaptación

Adaptación

Adaptación

Detección

Detección

Detección

MensajesMensajes

Red

Mensajes

Interfacesde usuario

Informacióncontextual

Figura 6.1: Instancias del marco XARE en los dispositivos moviles

soluciones basadas en la Web, donde el dispositivo huesped actuan como cliente y laentidad externa como servidor;

2. la entidad externa pregunta a los dispositivos huespedes acerca de sus capacidades.

En el caso de los dispositivos huespedes con suficientes caracterısticas para instanciar com-pletamente el marco XARE, ellos podran comunicarse con los demas dispositivos mediantemensajes transmitidos por la red. En cambio, los dispositivos huespedes que utilizan una en-tidad externa, ellos se comunicaran con los demas dispositivos por medio de dicha entidadexterna. Las instancias del marco XARE podran comunicarse con las bases de datos a travesde la red, para obtener u actualizar la informacion adecuada.

La comunicacion entre instancias del marco XARE requiere la API mostrada en la tabla 6.1.En donde se muestra el envıo y la recepcion de mensajes.

Capıtulo 6 155

Nombre Descripcion Errores

Boolean Send Messages(Message, Devices Array)

Se envıa un mensaje a los dispos-itivos contenidos en el arreglo

Clase contenedora:

Comunication

Salida: Exito o fracaso enel envıo del mensaje

No se encuentra el dis-positivo

Boolean Receive -Message (Message)

Recibe mensaje

Clase contenedora:

Comunication

Salida: Exito o fracaso enla recepcion del mensaje

Mensaje danado

Tabla 6.1: API de la comunicacion entre instancias del marco XARE

6.2 API de comunicacion entre las capas

Como se dijo en la seccion 5.3 del capıtulo 5, el marco XARE esta compuesto por las siguientescapas: espacio de trabajo, deteccion y adaptacion.

API de la capa de espacio de trabajo

Esta capa es responsable de llevar a cabo la adaptacion acordada por la capa adaptacion. Enla tabla 6.2


Void Update Session(ID Collaborator,ID Session)

Actualiza la sesion al registrar suinicio de sesion un colaborador

Clase contenedora:

GroupOfCollaborators

Salida: No aplica

No se encuentra lasesion

Continua en la pagina siguiente



Void Dis-play Availability (Ob-servedUser)

Muestra la disponibilidad delcolaborador observado

Clase contenedora:

UserInterface

Salida: No aplica

No se encuentra el co-laborador observado

Void Display Contact-Means (ObserverUser)

Muestra los medios de contactodisponibles que puede tener elcolaborador observador

Clase contenedora: User-Interface

Salida: No aplica

No se encuentra el co-laborador observado

Void Display MetaIU(Array, ID Device)

Muestra una meta interfaz deusuario con las opciones incluidasen un arreglo sobre el dispositivoindicado


Salida: No aplica

Problemas deconexion con eldispositivo

Void Display Desktop(ID Collaborator,ID Device)

Actualiza el desktop de un colab-orador en un dispositivo


Salida: No aplica

Problemas deconexion con eldispositivo

Tabla 6.2: API de la capa de espacio de trabajo

API de la capa de adaptacion

Esta capa analiza la informacion obtenida por la capa deteccion para determinar si los nuevoscambios en el contexto de uso requieren o no la adaptacion de los espacios de trabajo publicos o

Capıtulo 6 157

privados de una aplicacion colaborativa. Cuando la capa adaptacion considere que la adaptacional cambio contextual es necesaria, esta capa informa a la capa espacio de trabajo como debe serimplementada dicha adaptacion.

La API de la capa de adaptacion se muestra en la tabla 6.3


String Create Deixis(Deictic Word,ID Document, ID Shared-Object)

Crear una referencia deıctica deuna imagen o un texto

Clase contenedora: Link

Salida: Referencia Deıctica

No se encuentra el ob-jeto

Void Show Deixis(ID Deixis)

Despliega el objeto que estaligado a dicha deixis


Salida: No aplican

No se encuentra la ref-erencia deıctica

Image Cre-ate ImageCopy(ID Deixis)

En el pizarron multiusuario secrea una copia (ID ImgCopy) dela imagen referenciada


Salida: Genera una copia

No se encuentra la ref-erencia deıctica

Boolean Follow Conver-sation (ID SuggestConver,ID CurrentConver)

A un grupo que lleva una con-versacion se le sugiere ver laconversacion de otro grupo

Clase contenedora: Com-munication

Salida: Verdadero o falsodependiendo si el colaboradorsigue o no una conversacion

No se encuentra lasconversaciones




Image Update ImgRef(ID ImgCopy)

La copia de la imagen refer-enciada es actualizada en sudocumento fuente

Clase contenedora: Image

Salida: Actualiza la imagenfuente

No se encuentra lacopia de la imagen, oexisten problemas deescritura en el docu-mento fuente

Boolean Adapt Desktop-Collaborator (Array -Collaborator, Array-Device, ID Collaborator)

Adapta el desktop del colabo-rador considerando el rol y losdispositivos en uso

Clase contenedora: RichDesk-top

Salida: Devuelve verdaderoen caso de adaptar la interfez deusuario, en otro caso regresa falso

No se encuentra el co-laborador

Void Up-date Knowledge Tools(Array CollectedGroup,Array DistributedGroup,Array Asent Group)

La barra de conciencia es actual-izada cada vez que se detecta uncambio en la configuracion delgrupo

Clase contenedora: Col-laboratorBar

Salida: No aplica

No se encuentra labarra

String Calcu-late Availability (Ob-servedUser, ObserverUser,Observer Activities)

Calcula la disponibilidad delcolaborador observado

Clase contenedora: Avail-ability

Salida: El tipo de disponi-bilidad

No se encuentra el co-laborador observado oel observador


Capıtulo 6 159


String Calcu-late SimilarityActivities(ObservedUser, Ob-serverUser)

Calcula la similitud de las activi-dades de dos colaboradores

Clase contenedora: Activ-ity

Salida: El grado de simili-tud


String Calculate-ContactMeans (Ob-servedUser, ObserverUser,ObservedUser Disponibil-ity, ObservedUser Device,ObserverUser Device)

Obtiene los medios de contactodisponibles entre dos colabo-radores

Clase contenedora: Con-tactMeans

Salida: Los dispositivosdisponibles para la conversacion


Tabla 6.3: API de la capa de adaptacion

Capa de deteccion Esta capa se encarga de detectar de manera automatica algun cambioocurrido en el contexto, i.e., los eventos relevantes tanto externos como internos en la aplicacion.La API de la capa de deteccion se muestra en la tabla 6.4.


Boolena Up-date DeviceList (Array,ID Device)

Actualiza las caracterıstica deldispositivo

Clase contenedora: Hard-ware

Salida: Verdadero en casode encontrar el dispositivo; falsoen caso contrario





Boolean Up-date Collaborator(Array, ID Collaborator)

Actualiza el perfil y preferenciasdel colaborador

Clase contenedora: Col-laborator

Salida: Verdadero cuandoencuentra el colaborador, falsode otro modo


Boolean Up-date Collaborator(Time, ID Room,ID Collaborator)

Actualiza la ubicacion fısica deun colaborador, ası como sutiempo de ingreso



No se encuentra elID Colaborador

Boolean Link Device(ID Device,ID Collaborator)

Establece el dispositivo que estausando un colaborador




String Get Collaborator(ID Collaborator)

Regresa el perfil y rol del colabo-rador


Salida: Un arreglo con lainformacion mencionada



Capıtulo 6 161


StringGet Characteristics-Device (ID Device)

Regresa las caracterısticas de undispositivo en especıfico


Salida: Un arreglo con lainformacion mencionada


Boolean Up-date Configuration-Group (ID Collaborator,ID Group)

Agrega un miembro a un grupoco-localizado o distribuido

Clase contenedora: GroupOf-Collaborators

Salida: Verdadero en casode encontrar el grupo; falso encaso contrario

No se encuentra elgrupo

BooleanSave ConfigSession(Array Collaborator, Ar-ray)

Guarda las configuraciones de ungrupo

Clase contenedora: GroupOf-Collaborators

Salida: Verdadero cuandono ocurrio ningun error, de otromodo falso

No se pudo guardar laconfiguracion

StringGet Currently Activities(ID Collaborator)

Regresa la actividad actual delcolaborador ası como la fechalımite de esta

Clase contenedora: Activ-ity

Salida: Actividad actualy fecha lımite


Tabla 6.4: API de la capa de deteccion


6.3 Sıntesis

Las APIs necesarias para el funcionamiento de cada capa del marco fueron mostradas en estecapıtulo, de tal forma que se indica el tipo de valor que regresa dicha API ası como los tiposde valores que recibe. Se incluyo tambien algunos errores que deben ser considerados.

Estas APIs involucran varias partes de un sistema, i.e., dsde el despliegue de las interfacesde usuario hasta la deteccion de eventos fısicos y virtuales.

En este capıtulo se se muestra como podrıa ser instanciado el marco en los diferentes dispos-itos de computo, ya que estos estan cambiando constantemente en caracterısticas de hardwarey software.

Capıtulo 7

Conclusiones y trabajo a futuro

Como preambulo a emitir en las conclusiones de este trabajo, es muy importante recordar queel contexto de este estudio no esta reducido a un campo limitado de aplicaciones particulares,sino al ambiente de hoy en dıa en el que todos los usuarios estan progresivamente entrando demanera insoslayable: el usuario utiliza cada vez mas los dispositivos fijos y moviles del ambientedonde esta interactuando con otros usuarios moviles mediante aplicaciones interactivas queofrecen interfaces sofisticadas de trabajo colaborativo multimedia incluso multimodal. Ası, lasinterfaces de colaboracion son complejas, pero las caracterısticas de los potenciales dispositivosde interaccion son muy diversas. Ademas, el usuario es mas exigente y ahora quiere no solamentepoder pasar de un dispositivo a otro, sino usar de manera simultanea diversos dispositivoscombinandolos para definir un ambiente de interaccion sofisticado y eventualmente mas naturalpara colaborar de manera local y/o remota con otros usuarios.

En el marco de tal ambiente, este tema de investigacion se centra en proveer una definicion decontexto de uso para los sistemas colaborativos, la cual sirvio para crear un marco de desarrollode aplicaciones colaborativas adaptables al contexto que considera tanto la interfaz de usuariocomo el trabajo generado por cada colaborador.

El area del trabajo colaborativo se ve enriquecido con este trabajo de investigacion porquedefine el contexto de uso de los sistemas colaborativos, el cual esta basado en el contexto deuso de los sistemas mono-usuario.

En este trabajo de investigacion el contexto de uso de los sistemas colaborativos es ejempli-ficado por varios escenarios. Algunos de estos fueron implementados en aplicaciones colabora-tivas. A partir de estos escenarios se propone un marco de desarrollo ası como un conjunto deAPIs que permiten a los desarrolladores de software disenar aplicaciones colaborativas capacesde adaptarse al contexto en el cual se estan ejecutando.

Enseguida presentamos mas a detalle las conclusiones resultantes hasta el momento, ası comolos temas a investigar y desarrollar mas adelante para obtener resultados mas completos.

163

164 Conclusiones y trabajo a futuro

7.1 Conclusiones

En este trabajo introducimos la subarea del campo de Interaccion Humano-Computadora (IHM)llamada “Plasticidad de las Interfaces de Usuario”; con la finalidad de evolucionar las inter-acciones de los usuarios, que antes trabajaban individualmente, hacia el trabajo colaborativousando dispositivos heterogeneos, debido a que la importancia de dicha subarea, Trabajo Co-laborativo, parece cada vez mas importante. El desarrollo del presente trabajo de investigacionse centra en considerar varios puntos relevantes de este entorno de colaboracion creciente, paradefinir una interfaz de usuario plastica en la etapa de diseno y/o en tiempo de ejecucion.Tambien, los sistemas plasticos deben informar al usuario final acerca de las caracterısticas dela nueva adaptacion, ya sea que el usuario intervenga en el proceso de adaptacion o solo sea unobservador pasivo.

Varias de las aplicaciones que presentamos como ejemplos en este trabajo permiten expresarde manera visual la plasticidad, e.g., cambiar de modalidad grafica a textual cuando el dispos-itivo no soporta la modalidad grafica tal como la aplicacion lo requiere; redistribuir la interfazde usuario entre dispositivos heterogeneos (e.g., pizarrones electronicos, PDA, PC y mesas) y/oadaptarse a la tarea de un colaborador particular.

A partir de estos ejemplos, podemos observar que la mayorıa de los sistemas se focalizan en laplataforma (dispositivo, sistema operativo, sistema de interaccion y herramientas de software).Principalmente, estos sistemas se ejecutan sobre PDAs, tablets PC y/o computadoras portatiles;en cambio, el uso de dispositivos como pizarrones electronicos, telefonos inteligentes o relojesconstituyen plataformas no tan usadas frecuentemente. Muy pocos de los sistemas existentesconsideran al usuario, ası la tendencia respecto al usuario se limita a: i) considerar sus tareas(frecuencia y preferencia) o ii) determinar si un usuario esta usando dos o mas dispositivos.

Los marcos conceptuales o de desarrollo que son analizados en este trabajo de investigacionfueron seleccionados debido a que implementan algunas de las caracterısticas de las interfacesde usuario plasticas multimodales.

A partir del analisis de estos marcos con respecto al contexto de uso se puede observar queexiste una tendencia a tomar en cuenta varias peculiaridades del usuario, e.g., su perfil, sustareas asignadas y su rol, con la finalidad de proveer una mejor adaptacion. Las caracterısticasanteriores contemplan ciertas acciones en especıfico, e.g., detectar las preferencias respecto a untema. Por otro lado, la adaptacion a la plataforma se centra en acoplarse a las caracterısticasque ofrece cada dispositivo de computo, pero la tendencia en este punto es considerar sensorespara permitir la conciencia del entorno fısico, ademas de crear de manera dinamica clusterscon los dispositivos al alcance de los usuarios. En cuanto la adaptacion al entorno, los marcosestan tendiendo a modelar el entorno fısico, e.g., detectar las personas en un lugar, ası comoproporcionar informacion relevante a cada usuario dependiendo de su ubicacion.

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 mediante

Capıtulo 7 165

una meta-interfaz de usuario, ası como realizar la adaptacion de la aplicacion en tiempo deejecucion, dejando de lado los demas puntos a considerar.

Un marco organizacional de clases y mecanismos

En este trabajo de tesis proponemos un marco organizacional de clases (diagrama de clases)cuyo objetivo es constituir una referencia para disenar aplicaciones plasticas colaborativas,ya que se pueden observar las dependencias que existen entre las clases y las dimensiones delcontexto de uso. Dicho diagrama fue definido considerando los escenarios propuestos, los cualesfueron analizados como pre-requisito a este trabajo de investigacion.

En particular, en este trabajo proveemos una sıntesis de los mecanismos que permiten im-plementar cuatro de los siete escenarios descritos en esta tesis. El escenario que considera losobjetos compartidos, el cual se refiere a crear ligas entre una palabra clave de la mensajerıainstantanea y un objeto compartido del editor colaborativo mediante la funcion Deixis, puedeser implementado mediante el mecanismo para la “creacion de referencias deıcticas”. Estemecanismo podrıa permitir crear ligas no solo desde la aplicacion de mensajerıa instantaneasino desde cualquier otra aplicacion.

En el caso especıfico del escenario que soporta la modificacion de componentes mediante laocultacion, agregacion y/o sustitucion de un componente de la interfaz de usuario, este se puedeimplementar usando mecanismos dedicados que permitan adaptar los componentes dependiendode los roles del colaborador y del conjunto de dispositivos en uso. Estos mecanismos puedenusarse para ocultar los ıconos no relacionados con el rol del usuario (sus actividades), cuandola pantalla del dispoposiblessitivo en uso tenga una baja resolucion o sea de tamano muypequeno. Ademas las aplicaciones pueden optar por calcular la remodelacion de la interfazde usuario en el caso de que el dispositivo soporte dicho calculo o usar un servidor para queeste les proporcione la interfaz de usuario considerando las caracterısticas del contexto actual(dispositivos y colaboradores).

El escenario que presenta la adaptacion de componentes en interacciones co-localizadas, dis-tribuidas o hıbridas puede llevarse acabo utilizando los dos mecanismos siguientes: 1) el mecan-ismo de “deteccion de proximidad logica” que permite identificar si el grupo de colaboradoresse encuentra trabajando en la proximidad de puntos de intereses comunes, mientras que 2) elmecanismo de “deteccion de proximidad fısica” permite determinar si el grupo de usuarios estatrabajando en un mismo lugar o a distancia.

El escenario que introduce la adaptacion de los medios de contacto y disponibilidad de loscolaboradores puede llevarse acabo al usar los siguientes tres mecanismos que permiten: 1)determinar “la similitud de las actividades” de dos colaboradores, 2) calcular “la disponibilidad”de los colaboradores tomando en cuenta la similaridad de las actividades del usuario a contactary del que desea establecer el contacto, y 3) definir “los medios de contacto” considerando ladisponibilidad y los dispositivos de interaccion de los colaboradores.

De igual manera, se introdujo un escenario que presenta el principio de la adaptacion dela informacion, cuyo objetivo es proveer informacion dado un contexto determinado. Este


escenario puede ser implementado casi por completo al usar los siguientes mecanismos: 1)el mecanismo de “ocultacion, sustitucion y despliegue” de componentes que se puede usarpara proveer informacion necesaria en funcion del rol del colaborador y del dispositivo en uso,2) el mecanismo de “ubicacion fısica” que nos permitira saber el momento en que entra uncolaborador a un lugar especıfico y ası proveer la informacion adecuada dados sus roles y susactividades, y 3) el mecanismo de “similitud de actividades” que permite detectar la similitudde actividades entre dos colaboradores.

Finalmente, un escenario especıfico ilustra el uso de diferentes modalidades, cuyo objetivoes la notificacion de informacion usando diferentes modalidades de eventos relacionados con laubicacion de un colaborador, la actualizacion de informacion relevante para los colaboradores,ası como la actividad que esta llevando en cierto momento. Este escenario se puede implementarparcialmente al usar los siguientes dos mecanismos: 1) el mecanismo de “ubicacion fısica” paraconocer en donde se encuentra un colaborador y ası determinar si esta solo o acompanado, y2) el mecanismo de “similitud de actividades” para determinar si la actividad del colaboradoresta relacionada con la actividad de quien potencialmente recibira la notificacion.

En especıfico estudiamos en profundidad los escenarios que tienen implementadas sus apli-caciones. Algunas de las aplicaciones desarrolladas (e.g., la herramienta de votacion y el editorde mapas mentales) combinan algunos aspectos propuestos en los escenarios mencionados, locual permitio generalizar la adaptacion de dichas aplicaciones al rol, al dispositivo y a la con-figuracion del grupo. A partir de la herramienta de desktop enriquecido se pudo generalizarla manera de referenciar objetos compartidos entre dos aplicaciones, ası como de detectarcuando se hace referencia de manera directa o indirecta a un mismo objeto compartido. Conla aplicacion de disponibilidad y medios de contacto se generalizo la manera de calcular ladisponibilidad de los colaboradores y sus medios de comunicacion mas adecuada. En cambio,el administrador de contenidos NFC no se pudo generalizar dicho proceso, pero si nos permitiodestacar algunas de las variables contextuales a considerar.

Las cinco aplicaciones presentadas en esta seccion han sido implementadas para soportarel trabajo colaborativo, algunas de ellas permiten tanto el trabajo co-localizado como el dis-tribuido, pero otras solo una de esas dos opciones.

Las herramientas que permiten tanto el trabajo co-localizado como el trabajo distribuidocorresponden a: herramienta de votacion y editor de mapas mentales. Ambas aplicacionescomparten una barra de colaboradores. Dicha barra se adapta dependiendo del modo de tra-bajo.

Las herramientas que solo soportan el trabajo distribuido corresponden al desktop enriquecidoy a la herramienta de disponibilidad y medios de contacto. La herramienta desktop enriquecidopermite ejecutar tres aplicaciones y crear ligas entre objetos compartidos. La herramientade disponibilidad y medios de contacto permite adaptar dichos componentes (disponibilidady medios de contacto) considerando las actividades de los colaboradores involucrados, i.e., elcolaborador que desea saber la disponibilidad de otro colaborador.

Capıtulo 7 167

El administrador de contenidos vıa NFC solo permite el trabajo co-localizado. Dicha her-ramienta provee documentos relacionados a una reunion, considerando la fecha de la reunion.

XARE - un marco de desarrollo

La aportacion principal de este trabajo de investigacion consiste en proponer un marco dedesarrollo denominado XARE para orientar y ofrecer mecanismos basicos a los desarrolladoresy ası ayudarlos a definir aplicaciones adaptativas al contexto considerando cinco de las sietedimensiones de la plasticidad orientada a los sistemas mono-usuario. Las cinco dimensionesconsideradas en el marco corresponden a: 1) contexto de uso, 2) meta-interfaz de usuario cono sin negociacion, 3) medios de adaptacion (remodelacion y redistribucion), 4) granularidadde adaptacion y 5) granularidad de recuperacion del estado. La dimension contexto de usoes la mas estudiada en este tema de investigacion, ya que ha sido definida para los sistemascolaborativos y ha sido abordada en todos los escenarios presentados, e.g., adaptacion de laaplicacion al rol y perfil del colaborador (grupo de colaboradores), a los dispositivos (conjuntode plataforma) y a los objetos compartidos en uso (entorno compartido).

Algunos componentes del contexto de uso estan relacionados al medio de contacto y a ladisponibilidad, los cuales resultan interesantes de analizar cuando el sistema interviene paraestablecer de manera automatica las opciones disponibles. El medio de contacto ofrece a cadacolaborador las herramientas disponibles para ser contactado, dependiendo de algunas carac-terısticas propias del colaborador (plataforma, disponibilidad, actividad y el tiempo final dela actividad actual) ası como de los colegas que desean contactar. Como lo vimos, exami-nando el escenario ilustrado, el mecanismo de “disponibilidad de un colaborador”, el estado dedisponibilidad de un colaborador depende de la similitud entre su actividad y la de sus colegas.

Las dimensiones de plasticidad de una aplicacion colaborativa se caracterizan determinandoi) si la aplicacion necesita la adaptacion de una unica entidad o de diversas entidades, ii) quetipo(s) de variable(s) contextual(es) es(son) considerada(s) para la adaptacion y iii) que tipode adaptacion (presentacion, ejecucion y aumentacion) es requerido. A partir del analisis deldiagrama de clases del marco XARE, se puede observar que solamente una mınima parte deeste diagrama considera la dimension “entidad unica”, especialmente para la asignacion deroles o la disponibilidad del colaborador, ya que se considera a cada colaborador por separado.En cambio, la mayor parte del diagrama considera la situacion de varias entidades de formasimultanea, e.g., un documento formado por varios objetos compartidos es creado por uno ovarios colaboradores y la interfaz de usuario de cada colaborador se puede ver restringida por laplataforma de los colaboradores y las actividades que cada uno este desempenando al momentode contactar a un colega.

Las variables contextuales que intervienen en la propuesta de los sistemas colaborativos adap-tativos son varias, e.g., para establecer el medio de contacto se requiere conocer la plataforma,la actividad, la disponibilidad de un colaborador y la fecha actual, la cual permite saber quetan cercana es la fecha lımite de la actividad en curso. Por otra parte, las acciones de loscolaboradores pueden ser explotadas con el fin de que la aplicacion detecte cuando dos o mascolaboradores estan haciendo referencia sobre un mismo objeto compartido.


Las variables contextuales son igualmente muy utiles y comunmente usadas cuando se re-quiere tener un conocimiento actualizado del rol del colaborador para actualizar su ambientede trabajo, e.g., para mostrar solamente las funciones que le estan permitidas. Finalmente lascondiciones grupales permiten mostrar si los colaboradores trabajan de manera colocalizada odistribuida.

Analizando el tipo de adaptacion (presentacion, ejecucion y aumentacion) introducida en elpresente trabajo 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 comunicaciones con un colaborador: en este caso, el sistema solo presentaaquellas opciones que estan disponibles para ambos colaboradores. El tipo “ejecucion” se llevaa cabo cuando el sistema asigna de manera automatica el rol, la disponibilidad y el medio decontacto. Finalmente, la informacion aumentada se proporciona cuando el sistema detecta quedos o mas colaboradores estan haciendo referencia a un objeto compartido, e.g., un colaboradordescribe un diagrama, mientras otro modifica el mismo diagrama. Otro caso en que se usa lainformacion aumentada es cuando dos o mas colaboradores hacen una referencia deıctica a unobjeto compartido; en este caso ellos pueden tener a la vista dicho objeto al dar clic sobre laliga.

7.2 Trabajo a futuro

Algunos de los puntos mas relevantes a considerar en los desarrollos futuros de este trabajo deinvestigacion son los siguientes: i) automatizar algunos escenarios, ii) poner el marco XARE adisposicion de desarrolladores para que sea evaluado, iii) depurar las librerıas que implementanel marco, iv) ofrecer una aplicacion para un sector de aplicacion especıfico y evaluarla, asıcomo v) abordar las demas dimensiones propuestas en el ambito de las interfaces de usuarioplasticas mono-usuario y vi) eventualmente proponer su adaptacion en un ambiente de trabajocolaborativo.

La automatizacion de los escenarios que han quedado pendientes permitira enriquecer elmarco de desarrollo propuesto mediante clases y mecanismos. Los escenarios pendientes seenlistan a continuacion:

• Identificar al menos una aplicacion del escenario que permite ocultar la informacion,e.g., imagenes y texto, para que los colaboradores no se preocupen por la informaciondesplegada en sus pantallas ante la presencia de personas no autorizadas.

• Automatizar el escenario que permite usar diferentes modalidades para notificar eventosinternos y externos al sistema. El objetivo de este escenario es proveer una adecuadanotificacion de eventos que involucren diferentes modalidades considerando la actividadactual del receptor, ası como su ubicacion y la relevancia de dicha notificacion.

Capıtulo 7 169

• Automatizar aun mas el escenario que provee informacion con la finalidad de enriquecerla colaboracion, mediante informacion necesaria para un mejor desempeno de los colabo-radores.

Otro punto muy importante que queda pendiente es ofrecer el marco de desarrollo XARE adesarrolladores de software para que ellos evaluen la utilidad de dicho marco.

El trabajo a futuro que se refiere a depurar las librerıas que implementan el marco de de-sarrollo tiene como finalidad poner dichas librerıas a disposicion de cualquier desarrollador quedesee crear colaborativas conscientes de contexto.

El punto que se focaliza a ofrecer una aplicacion a un sector especıfico, e.g., el area medica,tiene como objetivo incorporar la mayorıa de las adaptaciones que ofrece el marco XARE enuna sola aplicacion. El objetivo es ofrecer una aplicacion para que los trabajadores de dichosector evaluen la utilidad de las adaptaciones que esta ofrece.

En este tema de investigacion se abordaron cinco de las siete dimensiones identificadas en eldiseno y la implementacion de las interfaces de usuario plasticas orientadas a los sistemas mono-usuario. Ası la consideracion del espacio tecnologico y del despliegue de la interfaz de usuarioconstituye el ultimo punto a considerar en el trabajo a futuro de este trabajo de investigacion.


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.

[Buvac et al., 1995] Buvac, S., Buvac, V. and Mason, I.A., Metamathematics of contexts, Fun-damenta Informaticae, 23 (3), pp. 412–419, 1995.

[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, D., Mendoza, D., Sanchez. G. and Rodrıguez, J., Adapt-ing 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 … · 2014-08-28 · CENTRO DE INVESTIGACION Y DE ESTUDIOS´ AVANZADOS DEL INSTITUTO POLITECNICO´ NACIONAL UNIDAD ZACATENCO