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