2

A mis padres, Myriam y Gaad, a mis hermanos, Paloma, Julián, Gabriela y Luciano,

y a la familia y amigos que siempre han estado conmigo.

3

Índice

Índice.............................................................................................................................. 3 1. Introducción ................................................................................................................ 4

1.1 Terminología y notación........................................................................................ 6 1.2. Motivación ........................................................................................................... 8 1.3. Objetivos ............................................................................................................ 10 1.4. Metodología ....................................................................................................... 12

2. Trabajos relacionados................................................................................................ 15 2.1. Computadores en la educación............................................................................ 15 2.2. Trabajo colaborativo........................................................................................... 17 2.3. Interfaces basadas en gestos con lápiz y bocetos a mano alzada .......................... 20

3. Solución Propuesta.................................................................................................... 21 3.1. Arquitectura de información ............................................................................... 22 3.2. Casos de uso ....................................................................................................... 24 3.3. Interfaces de usuario........................................................................................... 27 3.4. Estructura de datos ............................................................................................. 41 3.5. Arquitectura de red ............................................................................................. 43

4. Implementación......................................................................................................... 44 4.1. Metodología de implementación ......................................................................... 44 4.2. Diseño del sistema .............................................................................................. 45 4.3. Implementación.................................................................................................. 48 4.4. Integración en una aplicación para simulación participativa................................ 67

5. Resultados................................................................................................................. 73 5.1. Sistema como plataforma para aplicaciones de trabajo colaborativo.................... 73 5.2. Sistema como plataforma para simulaciones participativas ................................. 78

6. Conclusiones ............................................................................................................. 79 6.1. Alcance de los objetivos ..................................................................................... 80 6.2. Trabajo futuro..................................................................................................... 80

7. Referencias ............................................................................................................... 84

4

1. Introducción

En la última década nuestro entorno ha ido cambiando sistemáticamente. Poco a poco los computadores han ido cobrando importancia en nuestras vidas, llegando a rodearnos cada vez más ubicuamente. Hoy es muy común que cualquiera de nosotros tenga en su bolsillo un teléfono celular (con una capacidad de procesamiento no menor) o, en algunos casos, un computador de mano. Estos dispositivos han ido madurando en sus capacidades, hasta superar con creces nuestras expectativas de las “agendas personales” que en su comienzo pretendían ser. Incluso, cuentan con las mismas virtudes que nuestros computadores principales: son capaces de almacenar grandes cantidades de información, reproducen música y películas, permiten exhibir presentaciones, y nos otorgan conectividad en lugares donde, hace algunos años, hubiéramos considerado fantasioso tener acceso a Internet y a toda la información con que esta red nos conecta.

Sin embargo, estos pequeños dispositivos, capaces de entrelazarse en nuestras vidas de manera tan sutil, no han cambiado sustancialmente la forma en que los computadores apoyan ciertas actividades: el software para dispositivos móviles está generalmente diseñado como una versión reducida de la original para computador de escritorio, sin buscar nuevas aplicaciones alternativas donde se aprovechen sus características únicas [Roschelle 2003]. La ubicuidad, fácil manipulación y, complementariamente, su capacidad de intercomunicarse, nos permiten abrir campos previamente sesgados por las tecnologías tradicionales [Colella 2000, Metcalf 2004, Klopfer 2004].

Particularmente, en las áreas donde las tecnologías de la información apoyan la interacción entre personas, los computadores han mantenido un rol distante, incorporándose con dificultad [Swan 2006]. Por ejemplo, uno de los usos con que nos hemos familiarizado enormemente en el último tiempo son las reuniones o clases apoyadas por presentaciones digitales, las que han venido promoviendo una comunicación cada vez más unidireccional entre el presentador y su audiencia, limitando las alternativas de cooperación e interacción, conceptos fundamentales en muchas actividades grupales [Baytelman 2004].

Por otra parte, la mayoría de las aplicaciones que han sido creadas para trabajar de manera colaborativa, llamadas groupware, están limitadas a computadores personales, sesgando los campos donde pueden ser aplicadas a aquellos escenarios dependientes de redes de infraestructura y servidores centralizados. Son escasas las alternativas que han logrado apoyar exitosamente actividades más espontáneas, permitiendo realizar sesiones colaborativas en entornos no predispuestos o en actividades donde el rol de la tecnología debe ser lo menos obstructivo posible.

En la actualidad no hay herramientas disponibles que permitan, en particular, realizar simulaciones participativas con objetivos educacionales complejos, donde los involucrados tengan roles activos en la simulación [Roschelle 2003, Swan 2006]. Incluso,

5

son escasas las herramientas que facilitan la asignación dinámica de grupos en actividades colaborativas sobre dispositivos móviles. Más aún, la mayoría de las aplicaciones enfocadas en el trabajo grupal permiten administrar la actividad, individual o cooperativa, y la distribución de los participantes sólo desde un PC, anclando la movilidad del proyecto al alcance de un computador de escritorio.

El principal objetivo de este trabajo es, entonces, crear una plataforma que permita desarrollar aplicaciones colaborativas, primordialmente simulaciones participativas. Tal como se describe en la sección Objetivos, se pretende construir un sistema extensible que permita a dispositivos móviles interactuar colaborativamente en problemas complejos mediante aplicaciones ad-hoc. Mediante estas aplicaciones, las actividades podrán ser lideradas por un coordinador, el que contará con la posibilidad de organizar grupos de trabajo dinámicamente. Así, a modo de ejemplo –y como se señala en la sección de Integración en una aplicación para simulación participativa-, un profesor podría determinar grupos de alumnos asignados a distintos roles dentro de una simulación; un jefe de proyecto, distribuir responsabilidades a equipos de trabajo; un grupo de profesionales, proponer ideas de manera independiente y compararlas para una toma de decisiones conjunta, entre otros posibles usos.

A continuación se describirá de manera más profunda la motivación de este proyecto, sus objetivos, los trabajos relacionados a la colaboración apoyada por dispositivos móviles y el plan de trabajo con que se pretende alcanzar dichas metas. Posteriormente se encuentra, también, la descripción de la experiencia del desarrollo de los objetivos, así como el diseño, implementación y puesta en marcha del proyecto. La memoria concluye mostrando sus resultados, aplicaciones actualmente implantadas propuestas para posibles escenarios futuros y conclusiones del trabajo.

6

1.1 Terminología y notación

Mapas conceptuales: Representación gráfica de las ideas que permite organizar la información de acuerdo con relaciones causales, niveles de jerarquía o procedimientos. La elaboración de esta representación requiere el desarrollo de procesos de transferencia, discriminación, jerarquización y síntesis. Es un excelente recurso para la comprensión de ideas, ya que al organizar la información facilita la reconstrucción de significados

Programa Informático Colaborativo o Groupware (inglés): Programas informáticos que integran el trabajo en un sólo proyecto con muchos usuarios concurrentes que se encuentran en diversas estaciones de trabajo, conectadas a través de una red. En su forma moderna, el concepto ha sido propuesto por el programa informático de Lotus Notes relacionado con un servidor Lotus Domino algunas revisiones históricas argumentan que el concepto fue anticipado antes por sistemas monolíticos como el NLS.

Colaboración o Cooperación: Trabajo conjunto orientado en la obtención de un objetivo común. Algunas fuentes denotan diferencias entre estos conceptos, especificando que la colaboración depende del aporte único de cada participante. Particularmente, en este trabajo, nos referiremos a ambos conceptos de manera equivalente.

Handhelds o computadoras de mano: Computadores de bolsillo, comúnmente equipados con pantallas sensibles al tacto. Se han popularizado recientemente, incluso convergiendo con los dispositivos de telefonía móvil. Las principales referencias comerciales son Palm y las líneas PocketPC.

Stylus: Nombre con que se llama habitualmente al lápiz utilizado para interactuar con las pantallas sensibles al tacto, principalmente de dispositivos móviles así como pizarras electrónicas o Tablet PC’s.

Gestos mediante lápiz: Nos referiremos a “gestos mediante lápiz”, “gestos con el lápiz” o “gestos con stylus” a la interacción del usuario con la pantalla sensible de los dispositivos móviles mediante el lápiz o stylus. Los movimientos correspondientes a la escritura o dibujo natural o clics sobre la pantalla corresponden a gestos. Ellos pueden representar escritura y puntuación, así como la intención del usuario de realizar acciones alternativas.

Redes inalámbricas ad-hoc: Redes punto a punto creadas de manera dinámica sobre el protocolo IEEE 802.11. A diferencia de las redes inalámbricas de infraestructura, basadas en puntos de acceso, estas redes permiten que los equipos se comuniquen directamente entre sí, sin necesidad de contactarse mediante un router, mejorando la velocidad y liberando de carga a las redes de infraestructura del lugar. Las redes ad-hoc pueden ser creadas y adheridas por la mayoría de los computadores personales, notebooks y otros dispositivos con tarjetas de red inalámbricas, en particular las handhelds disponibles actualmente en el mercado (Julio, 2006).

7

Java: Lenguaje multiplataforma de programación orientada a objetos (OOP) creado por Sun Microsystems. Actualmente, 3.8 billones de dispositivos son capaces de reproducir aplicaciones desarrolladas en esta plataforma, destacándola como la solución más compatible con dispositivos móviles, así como computadores tradicionales.

J2ME o Java ME: La plataforma Java 2 Micro Edition, o Java ME (anteriormente J2ME), es una colección de instrucciones limitadas de la versión original de Java orientadas a productos de consumo como PDAs, teléfonos móviles o electrodomésticos. Java ME se ha convertido en una buena opción para crear juegos y aplicaciones livianas en dispositivos móviles debido a que se puede emular en un PC durante la fase de desarrollo y luego ejecutarlos fácilmente al teléfono.

.NET Framework: La plataforma .NET de Microsoft es un componente de software que puede ser añadido al sistema operativo Windows. Provee un extenso conjunto de soluciones predefinidas para necesidades generales de la programación de aplicaciones, y administra la ejecución de los programas escritos específicamente con la plataforma. Esta solución es el producto principal en la oferta de Microsoft, y pretende ser utilizada por la mayoría de las aplicaciones creadas para la plataforma Windows.

.NET Compact Framework: Set de instrucciones, basado en .NET Framework, disponible para dispositivos móviles compatibles con Microsoft Windows Mobile. Resume las principales funciones y estructuras de datos necesarias para el desarrollo de la gran mayoría de aplicaciones para handhelds y teléfonos inteligentes (SmartPhones).

Mobile Computer Supported Collaborative Learning (MCSCL): Metodología de enseñanza mediante participación colaborativa entre los alumnos, apoyada por dispositivos móviles.

Notación para métodos estáticos y locales: Cuando el texto se refiera a un método siendo invocado estáticamente, se utilizará el nombre de su clase con mayúsculas iniciales, mientras que cuando se utilice de manera local el objeto se denotará con el nombre de su clase con minúscula inicial. Como ejemplo, podemos distinguir que Drawable.GetDrawable() es un método estático, mientras que drawable.Draw() está siendo invocado desde una instancia de la clase Drawable.

Infrared Data Association (IrDA): Asociación que define un estándar físico en la forma de transmisión y recepción de datos por rayos infrarrojo. IrDA se crea en 1993 entre HP, IBM, Sharp y otros. Esta tecnología, basada en rayos luminosos que se mueven en el espectro infrarrojo. Los estándares IrDA soportan una amplia gama de dispositivos eléctricos, informáticos y de comunicaciones, permite la comunicación bidireccional entre dos extremos a velocidades que oscilan entre los 9.600 bps y los 4 Mbps. Esta tecnología se encuentra en muchos ordenadores portátiles, y en un creciente número de teléfonos celulares, sobre todo en los de fabricantes líderes como Nokia y Ericsson.

8

1.2. Motivación

Los dispositivos móviles surgieron hace más de 15 años. Desde entonces, se han popularizado a medida que su costo se reduce y sus capacidades, multiplican. Poco a poco, han sido incorporados [Rystedt 2001, Bae 2005] en entornos y actividades donde antes quedaban excluidos por su capacidad o costo. En particular, son múltiples las aplicaciones donde las handhelds han encontrado un espacio en torno a la educación [Jipping 2001, Vahey 2002, Metcalf 2004, Zurita 2004]. Pese a ello, las tecnologías móviles permanecen, en general, ausentes en las salas de clases [Swan 2006]. Tal como expone Swan et al., es necesario replantear las metodologías de enseñanza y aprendizaje para aprovechar de mejor manera las nuevas tecnologías disponibles: no basta sólo incorporar cada vez más computadores o handhelds en cada sala, sino que hay que reinventar el cómo la educación se involucra sinérgicamente con las tecnologías emergentes [Roschelle 2003].

El aprendizaje es una actividad principalmente social y el carácter individual de muchas aplicaciones computacionales ha detenido un avance más profundo de la tecnología en la sala de clases. Pese a que los computadores poseen una larga historia penetrando en el área educacional, gran parte de este esfuerzo se ha centrado en el aprendizaje individual o autoaprendizaje [Campbell 2003, Laurillard 2006]. Este enfoque convierte al computador en una herramienta que enseña y evalúa a un receptor individual, limitando la interacción con otros usuarios y, por ende, disminuyendo el éxito alcanzado al incorporar este tipo de tecnologías en entornos educacionales como colegios y universidades.

Lentamente las herramientas computacionales han permitido a los alumnos interactuar, relacionarse mutuamente y alcanzar objetivos educacionales de manera más satisfactoria. A través de una administración centralizada, estos elementos facilitan a los alumnos los procesos tendientes a resolver conjuntamente tareas y problemas desde computadores de escritorio, móviles o de mano [Cortez 2004, Cortez 2005, Zurita 2005]. Existen también iniciativas que permiten a los alumnos participar sincrónicamente con clases remotas.

Sin embargo, hay una carencia en torno a aplicaciones móviles colaborativas que permitan dinámicamente crear, asignar y distribuir tareas y objetivos en grupos cambiantes, formados en tiempo real. Pese a que actualmente algunas herramientas permiten la reconfiguración dinámica de grupos, e incluso asignación en línea de tareas y objetivos, no se cuenta con un sistema capaz de administrar y redistribuir grupos en tiempo real. Incluso, las más innovadoras aplicaciones ofrecen realizar la organización de grupos y distribución de contenidos y ejercicios a través de sistemas centrales basados en computadores tradicionales. En este escenario, hay una total ausencia de plataformas que permitan la creación dinámica de contenidos, tareas u objetivos.

Diversas metodologías tecnológico-educacionales, basadas en la distribución de grupos y creación de tareas, han demostrado alcanzar altos índices de efectividad en la sala de clases [Cortez 2005, Zurita 2005]. Las tareas colaborativas, donde la participación de cada alumno es necesaria para alcanzar los objetivos asignados, instan a los alumnos a interactuar activamente en la sala de clases. Particularmente, la simulación participativa,

9

práctica colaborativa donde cada persona asume un rol particular dentro del ambiente simulado, constituyendo una metodología de enseñanza en pleno desarrollo.

Experimentos académicos han demostrado cómo estas prácticas posibilitan que los alumnos se motiven y aprendan de manera más eficaz [Alonzi 2000, Colella 2000, Andrews 2003, Klopfer 2004, 2005]. Klopfer et al. [2005] muestran cómo estas simulaciones promueven la fácil adaptación a distintos temas e integración en las mallas curriculares, simplicidad para alcanzar objetivos propios de cada profesor, así como estimular la adopción de estrategias centradas en el alumno. Estos resultados coinciden con lo planteado en [Soller 2001], donde se sostiene que los alumnos aprenden de forma más efectiva al realizar las experiencias educativas de manera grupal y con apoyo de sistemas computacionales.

Debido a lo reciente de estos desarrollos, el potencial de las actividades colaborativas en la sala de clases, apoyadas por la tecnología, no ha sido explorado a cabalidad. A medida que empiezan a ser descubiertas posibles aplicaciones para las actividades colaborativas, en resolución de problemas, juegos y simulación participativa, surge un enorme campo donde nuevos avances pueden enfocarse en la implementación de estas soluciones. De este modo, la integración de las tecnologías móviles en torno a esta problemática promete ayudar a formar las aulas del futuro.

Queda así planteado el desafío de concebir e implementar dichas soluciones. Como paso inicial, y particularmente como objetivo de esta memoria, se desarrollará una plataforma para generar aplicaciones que, sobre dispositivos móviles y basado en gestos con el lápiz, brinden la capacidad de llevar a cabo distintas experiencias colaborativas orientadas a la sala de clases, sin excluir otros posible campos. Por lo tanto, también es necesario incorporar la capacidad de que el profesor o el monitor controlen la topología grupal dentro de la sala de clase, como ha sido mencionado en [Roschelle 2003].

Construir tal sistema plantea una serie de desafíos. Primero, los dispositivos móviles cuentan con menor capacidad de memoria y, por ende, ofrecen a los desarrolladores menos alternativas de alto nivel para crear aplicaciones complejas. Segundo, el trabajar sin el apoyo de redes preestructuradas (ya sea por cable o inalámbricas) ni de servidores centralizados obliga al sistema a ser capaz de generar configuraciones dinámicas, tanto en la definición espontánea de problemas y objetivos, como en la manipulación real de las interacciones entre los dispositivos de cada participante. Tercero, nos enfrentamos a una interfaz distinta a los computadores personales, donde es necesario encontrar nuevas maneras, adecuadas para que mediante dispositivos móviles los usuarios colaboren entre sí [Brewster 2002] de manera de presentar sólo la información relevante y no desperdiciar el limitado espacio disponible en las pequeñas pantallas. Cuarto, la necesidad de almacenar, construir y comunicar contenidos generados con anticipación o de manera dinámica obliga la concepción de una arquitectura de información capaz de responder a estas necesidades. Finalmente, es pertinente incorporar un sistema de organización de los participantes, ya sea de manera distribuida (donde cada quién decide formar parte o no de cierto grupo) o centralizada (donde un profesor o monitor organiza la topología del universo de participantes). Estos desafíos son analizados en profundidad en el siguiente capítulo, planteando objetivos concretos para enfrentarlos.

10

1.3. Objetivos

1.3.1. Objetivo general

El objetivo principal de este trabajo es diseñar, implementar y utilizar una plataforma para permita desarrollar aplicaciones que soporten actividades colaborativas, puntualmente simulaciones participativas, apoyadas por tecnologías móviles operados principalmente a través de gestos realizados con el lápiz.

Al hablar de “plataforma” nos referimos a desarrollar una API1 de colaboración, basada en .NET Compact Framework, que permita ser la base del sistema para luego integrarle las características adicionales necesarias para realizar una actividad colaborativa en particular. Esta base incluye todo lo necesario para intercomunicar los dispositivos de los participantes, permitir al profesor o monitor configurar y controlar la actividad. El programador deberá completar la aplicación implementando funcionalidad adicional, incrementando el sistema con las características particulares de la actividad o simulación seleccionada. Ello incluye el añadir capacidades adicionales tanto para el profesor como para los participantes.

Con el fin de evaluar la plataforma desarrollada, se generarán varias aplicaciones, en particular una enfocada en simulación colaborativa, permitiendo medir la versatilidad que la plataforma ofrece a través de ejemplos reales. Klopfer et al. [2005] muestra diversos campos donde la simulaciones participativas han sido aplicadas, y describe algunos campos donde los profesores destacan que ésta puede ser exitosa. Ello invita a buscar actividades donde la plataforma ofrezca un positivo impacto en las salas de clases. Las áreas, donde esto podría ser práctico en un marco universitario, son aquellas donde existen relaciones a) sociales, políticas y geográficas, b) computacionales, matemáticas y geométricas, c) económicas o d) biológicas.

1 API: Application Programming Interface, Interfaz de Programación de Aplicaciones (inglés) es un conjunto de especificaciones de comunicación entre componentes software.

11

1.3.2. Objetivos específicos

Definir los requisitos comunes para aplicaciones colaborativas móviles, incluyendo aquellos necesarios para actividades de simulación participativa.

1. Identificar:

a. Qué limitaciones tecnológicas poseen los dispositivos móviles y cuáles existen en los ambientes donde los sistemas serán utilizados,

b. Qué acciones son necesarias para (a) administrar las actividades y (b) participar de ellas,

c. Qué estructuras de datos es necesario soportar,

d. Cuáles son las interfaces adecuadas para llevar a cabo dichas acciones, y

e. Con qué estrategia establecer las comunicaciones entre los dispositivos.

2. Diseñar una plataforma, o API, para aplicaciones colaborativas que cuente con dichos requerimientos. En particular, desprendiendo del punto 2, determinar:

a. Arquitectura de información,

b. Casos de uso,

c. Interfaces de usuario,

d. Estructuras de datos, y

e. Arquitectura de red.

3. Implementar dicha plataforma.

4. Generar uno o más prototipos de aplicaciones colaborativas, en particular para apoyar simulaciones participativas, con el fin de evaluar constructivamente la plataforma.

5. Medir y evaluar los resultados.

6. Proponer una dirección para trabajo futuro, refiriéndose a mejoras para la plataforma, funcionalidades adicionales y posibles aplicaciones.

7. Concluir acerca de los resultados del presente trabajo.

12

1.4. Metodología

Esta sección describe las etapas que el actual proyecto siguió durante el trabajo para definir y luego satisfacer los objetivos planteados en la sección anterior. En este proceso se pueden distinguir tres etapas claras: su comienzo como búsqueda de un sistema móvil específico para el apoyo a reuniones, su creciendo para abarcar desarrollo colaborativo de material educacional, hasta su maduración como una plataforma completa en la búsqueda para ofrecer una base a un amplio rango de aplicaciones colaborativas, particularmente las simulaciones participativas.

1.4.1. Sistema móvil de soporte a reuniones

Durante esta etapa inicial se realizó un primer acercamiento a la temática de la colaboración, discutiendo en torno a sistemas de soporte a reuniones y toma de decisiones. Se plantea el objetivo de desarrollar un prototipo inicial que satisfaga necesidades particulares de la temática planteada.

Una vez establecidos los objetivos para esta etapa, se realizó una revisión bibliográfica inicial relacionada con actividades colaborativas y sistemas de apoyo a reuniones. También se investigó sobre interfaces para pantallas de tamaño limitadas, así como sensibles al tacto. Luego, como resultado de los requisitos propuestos y el estudio realizado, se llevó a cabo el diseño de la primera versión de la plataforma, la cual ofrecería la capacidad de interconexión entre dispositivos y desarrollo de material colaborativamente a través de gestos realizados con el lápiz. Este diseño planteaba la necesidad de una estructura de datos que permitiese el desarrollo y comunicación sincrónicos del material generado, un sistema de detección de gestos realizados con el lápiz, así como la necesidad de una biblioteca de comunicación que detectase a los participantes de manera automática y les permitiese comunicarse en redes ad-hoc establecidas dinámicamente.

Luego, se buscó las alternativas de desarrollo disponibles y se estudió sus ventajas comparativas. Las plataformas encontradas fueron C# y Java. Se optó por Java ya que el equipo de desarrollo tenía una amplia experiencia en dicho lenguaje, además de ofrecer independencia de sistemas operativos dentro de los disponibles para equipos móviles.

Posteriormente, se llevó a cabo dicha implementación. El sistema como un todo fue desarrollado por Felipe Baytelman, incluyendo la estructura general de la plataforma, así como las interfaces gráficas, detección de gestos y manipulación de los contenidos. La biblioteca de comunicación fue realizada por otro estudiante de la Universidad de Chile, como un trabajo independiente para Magíster en Ciencias de la Computación.

Finalmente, tras cuatro meses de trabajo, éste fue evaluado por un grupo de expertos en trabajo colaborativo, constituido por Pedro Antúnez, Antonio Ferreira, Marco Sá, Hugo Simões, Rui Lopes y Nelson Baloian, junto al autor de este trabajo. Como resultado tras esta primera etapa se cumplió el objetivo de implementar un primer prototipo de sistema móvil de apoyo a reuniones. La evaluación además permitió detectar necesidades adicionales para la plataforma, así como falencias gráficas en las máquina

13

virtual de Java disponible en ese entonces. También se pudo identificar qué interfaces gráficas cumplían bien su objetivo, así como cuáles presentaban dificultad de comprensión o uso por parte de los usuarios.

1.4.2. Perfeccionamiento de la plataforma básica e incorporación de modalidades de soporte al aprendizaje

Tal como ha sido mencionado, la primera etapa permitió alcanzar el objetivo inicial, dejando como resultado un prototipo de sistema móvil de apoyo a reuniones, así como un conjunto de propuestas de mejora incremental y corrección. Una de estas propuestas consistió en la migración a C#, lenguaje nativo a la plataforma Windows Mobile con que contaban los equipos disponibles para este trabajo. Este cambio permitió acceder de mejor manera a las capacidades gráficas de los dispositivos móviles, una de las mayores restricciones que Java establecía. Adicionalmente, fueron planteadas una serie de correcciones a la interfaz. Por último, la biblioteca de comunicación no fue del todo satisfactoria.

Por otra parte, surgió la inquietud de extender, paralelamente, la aplicación con el fin de apoyar la motivación en la sala de clases. Se planteó la posibilidad de aprovechar las funcionalidades colaborativas para ofrecer soluciones educacionales que incrementaran la motivación en las aulas. Se realizó una nueva búsqueda de material relacionado y bibliografía relacionada con la temática de computadores en la sala de clases, aplicaciones móviles educacionales y colaboración en la sala de clases.

Como resultado de estas investigaciones, se determinaron las necesidades adicionales que el sistema requeriría para satisfacer los requerimientos como software colaborativo dentro de la sala de clases. Se propuso, en base a estos requisitos, un diseño para la modalidad de trabajo grupal, así como para la asignación de tareas y evaluaciones para que los alumnos desempeñaran en conjunto. Finalmente, dichos requerimientos fueron implementados concretando un modo de trabajo para la administración y participación en tareas de manera grupal, donde el profesor es capaz de formar y administrar grupos de alumnos, así como construir actividades sobre la marcha y asignarlas a los participantes en su clase. En esta modalidad, tras asignar tareas a los distintos participantes, el profesor puede seguir el desempeño de cada grupo desde su dispositivo, permitiéndole evaluar tempranamente las respuestas de cada equipo, así como brindar ayuda remota a los alumnos.

1.4.3. Generalización de la plataforma: desde diseño colaborativo hasta simulaciones participativas

Los objetivos del proyecto se habían alcanzado con creces. Se desarrolló una plataforma capaz de soportar la creación de una gran variedad de aplicaciones para escenarios colaborativos: apoyo a reuniones de negocio y actividades de diseño in-situ, soporte para trabajo cooperativo en la sala de clase, formación espontánea y administración de grupos de alumnos, y evaluación así como asistencia remota en tiempo real dentro de la sala de clases. Tras haber creado exitosamente esta plataforma, surgió la inquietud de enfrentar nuevos campos educacionales, más innovadores y ambiciosos. Es

14

así como nace la idea de generalizar la plataforma, permitiendo construir un mayor rango de aplicaciones colaborativas en múltiples escenarios. Fue de particular interés abarcar el campo de las simulaciones participativas, actividades educacionales donde los alumnos participan de un modelo activamente mediante el apoyo de tecnologías móviles. De esta manera, se reconoce el objetivo final de este trabajo: el completar la plataforma de soporte a actividades colaborativas con herramientas y medios para permitir el desarrollo de aplicaciones de simulación participativa.

Las simulaciones participativas requieres de una extensa gama de funcionalidades, desde definición y asignación de roles, estructura de la actividad o juego a simular, configuración particular de cada instancia, control y monitoreo, hasta exposición y análisis de los resultados obtenidos. Esta metodología pretende que los alumnos o participantes se involucren en el proceso a simular, permitiéndoles experimentar y vivir la actividad de manera individual y activa. De esta manera, motivando a los alumnos a ser parte activa de la clase, se alcanzan mejores índices de aprendizaje [Larkin 2005].

En resumen, el proyecto descrito en el presente trabajo nació con el fin de desarrollar una aplicación para dar apoyo a reuniones de negocios y toma de decisiones, generalizándose luego en una plataforma para desarrollar múltiples aplicaciones colaborativas, para –finalmente- concluir abarcando el complejo mundo de las simulaciones participativas en la sala de clase. Abarca, así, un extenso rango de posibles aplicaciones, permitiendo a nuestro sistema apoyar las más variadas ramas de la colaboración en dispositivos móviles.

15

2. Trabajos relacionados

2.1. Computadores en la educación

2.1.1. Computadores en la sala de clases

[Bae 2005] realiza un estudio acerca de cómo la educación basada en la web y otras aplicaciones educativas han sido desarrolladas utilizando estrategias que estimulan y retienen la concentración del estudiante.

[Rystedt 2001] muestra el uso de simulaciones computacionales confines de entrenamiento individual para enfermería y medicina. En ellas, se utilizó un enfoque participativo, donde el estudiante se enfrentaba activamente al software. En el trabajo se reconoce que el entrenamiento con simulaciones constituye un apoyo a las prácticas tradicionales de enseñanza en esta área y que sus ventajas deben ser consideradas en el diseño de los currículos.

2.1.2. Dispositivos móviles como herramienta educacional

[Jipping 2001] plantea la utilidad que pueden tener los dispositivos móviles en la enseñanza de ciencias. Destaca su bajo costo y poder en aumento. En su proyecto se expone el uso de la plataforma CARDS para el desarrollo de aplicaciones educacionales para dispositivos móviles. Realiza el estudio de dos aplicaciones creadas con esta plataforma: una para el intercambio de objetos y otra para el aprendizaje de metodologías de testeo de software.

[Pinkwart 2003] realiza un análisis de tres herramientas sobre dispositivos móviles para cooperar en la sala de clases. Una aplicación es una herramienta para realizar anotaciones, la segunda replica un sistema de modelamiento sobre PDAs mientras que la tercera hace uso de lectores ópticos inalámbricos, además de los dispositivos móviles. En él, destaca los distintos modelos que las aplicaciones usan y concluye que, pese a la ubicuidad de los computadores de mano, el limitado tamaño de las pantallas restringe la efectividad del software.

La iniciativa Palm Education Pioneers (PEP) fue fundada por Palm Inc. El fin de ella es la de llevar un estudio sistemático sobre el impacto y posibles aplicaciones de las handhelds como herramienta educacional. Como parte de esta iniciativa, múltiples investigadores realizaron estudios relacionados con los dispositivos móviles en la sala de clases. En este marco podemos encontrar los trabajos de Roschelle, Tatar, Penuel, Crawford y Vahey.

[Vahey 2002] realiza el trabajo medular de la iniciativa PEP, obteniendo los siguientes resultados: Los profesores de enseñanza básica que participaron en el proyecto dieron una respuesta abrumadoramente positiva acerca del uso de computadoras de mano en la sala de clases: Cerca del 90% de los profesores aseguró que ellas son una

16

herramienta educacional eficiente, que tienen potencial para mejorar el aprendizaje y que seguirán utilizándolas en el futuro. Entre los beneficios obtenidos, los profesores destacaron el aumento de uso de tecnología, elevada motivación, colaboración y comunicación, así como los beneficios de una herramienta de aprendizaje portable y asequible. Por otra parte, se reconocieron como dificultades principales el uso inadecuado, los problemas relacionados con el desconocimiento de la tecnología, los problemas de usabilidad (particularmente relacionados con los métodos de entrada), así como daño sufrido por los equipos.

[Roschelle 2003] concluye acerca de las dificultades encontradas en busca de aplicaciones educacionales móviles. Destaca el potencial de muchos de estos estudios, pero reconoce la falta de consistencia desde un enfoque tecnológico así como desde uno social. Indica que es necesario el ponerse de acuerdo respecto a qué considerar “aplicaciones de educación móvil” y cómo lograr los objetivos sociales y tecnológicos: Las descripciones utilizadas en la literatura son vagas y no explican en qué manera los estudiantes interactúan con los dispositivos, las “aplicaciones pedagógicas” utilizadas en las investigaciones se centran en la tecnología y no en los objetivos educacionales, y la factibilidad de un “impacto a gran escala” depende de la capacidad de los investigadores y desarrolladores de concebir una plataforma común que satisfaga los objetivos pedagógicos, evitando la tendencia de fragmentar el mercado con soluciones puntuales aisladas.

17

2.2. Trabajo colaborativo

2.2.1. Colaboración y aprendizaje

[Cortez 2004 y 2005] muestran una iniciativa chilena para incorporar efectivamente tecnologías móviles en clases científicas para la enseñanza media. Esta experiencia guarda una gran similitud con el presente trabajo, puesto que su objetivo es el de mejorar el proceso de enseñanza incentivando la participación a través de una mayor motivación en clases. Para ello se generó un sistema MCSCL de apoyo a los profesores mediante dispositivos móviles interconectados inalámbricamente. Con este sistema, el profesor distribuye tareas previamente diseñadas entre los alumnos. Los alumnos, organizados en grupos, pueden resolver colaborativamente problemas basados en múltiples alternativas.

Este sistema fue probado en clases de física para la educación media donde obtuvo excelentes resultados, tanto cuantitativos como cualitativos: se logró construir un ambiente de alta motivación, donde los alumnos fueron capaces de construir nuevos conocimientos basados en los originales. Por otra parte, el sistema obliga a los profesores a diseñar y cargar anticipadamente las actividades en los dispositivos de los alumnos. Además, estos problemas se limitan a preguntas de selección múltiple, donde los estudiantes se encuentran limitados a respuestas cerradas.

2.2.2. Simulación participativa

El estudio correspondiente a los trabajos relacionados con simulación participativa guarda una estrecha relación con el presente trabajo. El siguiente es el análisis bibliográfico de los principales trabajos publicados a la fecha sobre simulación participativa:

Wilensky y Stroup [1999] proponen una nueva arquitectura, llamada HubNet, para realizar participaciones colaborativas. Este proyecto une dos líneas de investigación: los sistemas dinámicos complejos y el uso de simulaciones participativas como una poderosa herramienta para sistemas de modelamiento. Ambos enfoques pueden ser realizados mediante las tecnologías comunicacionales emergentes. La arquitectura propuesta se basa en el modelo cliente-servidor, identificando cada participante como un “nodo”, y ha sido aplicada en clases de enseñanza básica y media.

V. Colella [2000] publica la primera implementación y aplicación de una simulación participativa aplicada utilizando dispositivos móviles. En ella, los alumnos participan en una actividad donde deben intentar interactuar con el máximo de participantes posibles, bajo el riesgo de contagio de cierto virus. Inicialmente, algunos alumnos simulan están contagiados con la enfermedad, y los alumnos sanos se contagian con el virus sólo con interactuar con alguien infectado. Para aplicar esta actividad, cada alumno contaba con un Thinking Tag2, el que le permitía interactuar con sus compañeros 2 Dispositivo portátiles “vestibles” desarrollados por el Massachusetts Institute of Technology Media Labs, capaces de almacenar información e intercambiar datos mediante tecnología infrarroja.

18

enfrentando los puertos infrarrojos de sus dispositivos. El objetivo de dicho trabajo fue dar a conocer la metodología de simulación participativa y realizar un análisis de su implementación. Aunque las simulaciones de prueba fueron aplicadas a estudiantes de secundaria, la investigación no limita las simulaciones participativas a estudiantes escolares. Como resultado, los alumnos fueron capaces de inferir las reglas implícitas del micromundo simulado.

Peter Alonzi et al [2000] realiza una simulación basada en Microsoft Excel en computadores de escritorio, donde modela el mercado de futuros. En el modelo existe toda una serie de reglas y mecanismos utilizados, y los participantes adquieren el rol de personas que realizan transacciones bursátiles, concurriendo a un lugar donde transan sus acciones en voz alta. Paralelamente, existe una pantalla que muestra el estado global de las transacciones. El objetivo del proyecto fue analizar como la simulación participativa ayuda a comprender el mecanismo de la revelación de precio en el mercado de futuros, además de estudiar la aceptación de los estudiantes universitarios en la aplicación de este método de aprendizaje. La mayoría de los alumnos dijo que la simulación le ayudó a entender el sistema simulado (el concepto de descubrimiento de precio y el impacto de las tasas de interés en ellos). También señalaron que disfrutaron la experiencia y que querrían volver a repetirla. Ninguno consideró la experiencia como una pérdida de tiempo.

Truscott et al [2000] continúa investigando en el campo de las negociaciones, esta vez simulando el que representantes de 5 países negocien tratados comerciales, los cuales repercutirán en el bienestar del país. El fin de su investigación fue el presentar la incorporación de actividades participativas que involucren toma de decisiones y análisis de consecuencia en la enseñanza de temas de la macroeconomía.

Kimberley et al [2002] utiliza un acercamiento similar a [Colella 2000] incorporando Thinking Tags en clases de ciencias. En esta simulación los participantes tienen el rol de un genotipo y deben conocerse con otros participantes y observar una simulación del efecto que produce la unión de ambos.

Andrews et al [2003] también aplica simulaciones mediante Thinking Tags, esta vez a nivel de kindergarten. Los niños, portando sus dispositivos, se acercan y simulan ingerir algunos alimentos con distintas composiciones de azúcar, lo cual puede perjudicar la higiene bucal al provocar caries. El dispositivo rastrea tanto lo comido como la periodicidad del lavado bucal, para simular la aparición de caries. El objetivo de esta simulación era el mostrar como la metodología puede ayudar a que los niños comprendan de mejor manera la higiene bucal. Pese a que la tecnología no presentara innovadoras y atractivas interfaces pensadas en los infantes, durante el juego los niños hablaban de “sus” dientes o de si “tuvieron” caries o no, demostrando una alta motivación e inmersión en la actividad. Incluso, los niños alertaban y reprendían a otros cuando formaban caries.

Klopfer et al [2004] realiza los primeros acercamientos a dispositivos móviles más poderosos. En este trabajo, propone el análisis comparativo en la conveniencia de utilizar Thinking Tags y Palms para realizar simulaciones participativas. Así, obtuvo

19

pequeñas diferencias, suavemente inclinadas de manera positiva hacia la plataforma Palm, en términos de usabilidad y capacidad de recolección de datos. El hecho de que las handhelds puedan mostrar los resultados de manera más atractiva sugiere que puede ser una plataforma mucho más motivante a la hora de realizar juegos de simulación participativa.

Lonsdale et al [2004] utilizó mensajería SMS sobre teléfonos celulares en su proyecto. En él, los participantes tenían el rol de gotas de agua, a quienes se les enviaba SMS para indicarles una nueva situación (como, por ejemplo, que el sol evapora el agua), esperando a que se movieran al lugar de la habitación que corresponde (como del mar a las nubes). Su resultado fue medido a través de un mayor número de respuestas correctas en cuestionario post-simulación con niños escolares. Se puede destacar el cómo demuestra la factibilidad de implementar simulaciones participativas en teléfonos móviles, dispositivos populares y de bajo costo.

Klopfer et al [2005] plantea varias simulaciones sobre handhelds3: (1) Pez grande caza al pequeño para sobrevivir. El pez pequeño debe evadirlo para sobrevivir. (2) Participantes en desacuerdo en algún tema, se reúnen y tratan de convencer al otro que cambie de opinión. (3) Los participantes toman el rol de un simple genoma que debe sobrevivir. (4) Implementación del Dilema del prisionero. (5) Virus (igual a la experiencia en [Colella 2000] pero aplicado mediante Palms). (6) Sugar and Spice: Productores de azúcar y especies deben negociar intercambios para sobrevivir. Los jugadores deben identificar como funciona el sistema para optimizar sus estrategias de intercambio. El objetivo común de estas aplicaciones fue el descubrir la percepción de los profesores acerca de las cualidades educacionales de las simulaciones participativas. Se reconocieron los siguientes puntos: las simulaciones permiten una fácil adaptación a distintos temas e integración en las mallas curriculares, ofrecen simplicidad para alcanzar objetivos propios de cada profesor, así como para estimular la adopción de estrategias centradas en el alumno.

Daniel Marburger [2005] realiza una experiencia que compara el resultado de dos grupos, a los que se les enseñó el mismo contenido utilizando distintos métodos. Su objetivo fue analizar el impacto en el aprendizaje al utilizar métodos de aprendizaje cooperativo de la economía en contraste con el típico modelo de lectura-discusión. Para ello se aplicó un examen práctico con respecto a un caso en particular. Las respuestas correctas en ambos grupos no fueron significativamente distintas en las preguntas relativas con los contenidos del curso. Sin embargo, en las preguntas concernientes al caso de estudio real, existieron diferencias significativas que permiten concluir un aprendizaje más profundo en el grupo que realizó actividades cooperativas.

3 Más detalles en http://education.mit.edu/pda/

20

2.3. Interfaces basadas en gestos con lápiz y bocetos a mano alzada

El método más natural para interactuar con un handheld, el stylus, que imita el modelo mental de utilizar lápiz y papel, ha sido reconocido por varios autores como el más natural, ya que permite a los usuarios ingresar datos a mano alzada de manera fluida [Landay 2001, Lank 2004, Hinckley 2005]. Particularmente, el uso de gestos utilizando el lápiz es el más apropiado a la hora de manipular y controlar la información en las handhelds [Long 2005]. Sin embargo, cabe destacar que la gran mayoría del software para handhelds que utiliza de interfaces basadas en este principio ha sido diseñado para computadores personales, equipados con teclado y mouse [Brewster 2002, Dai 2005]. Estos widgets (botones, menús, ventanas, etc.) no son necesariamente los más apropiados para estos dispositivos. Los dispositivos móviles disponen de una pantalla pequeña, y este tipo de interfaz requiere de mucho espacio para ubicar estos elementos, ocupando un precioso espacio en el área de trabajo [Pinkwart 2003, Lund 2004, Collazos 2005].

De acuerdo a [Landay 2001], las aplicaciones de edición gráfica para los dispositivos móviles no requieren interfaces basadas en paletas y botones, y no necesitan contar con elementos como colores, tipografías o líneas. Ellos, en cambio, deberían basarse en el uso exclusivo de trazos naturales como interfaz de entrada, utilizando el sistema de dibujo libre a través del lápiz de los dispositivos móviles [Lank 2004, Dai 2005]. Aplicaciones utilizando este enfoque han sido diseñadas para escenarios como presentaciones informales con bocetos [Yang 2003] y diagramación de cursos para acciones militares [Forbus 2003], y para ser utilizado como métodos no tecnológicos para la generación de ideas en reuniones [Zurita 2006]. Pese a ello, ningún sistema ha sido desarrollado basándose únicamente en interfaces a través de lápices para administrar y utilizar toda la aplicación, tal como se realiza en computadores de escritorio mediante interfaces tradicionales basadas en Mouse y teclado [Fan 2003].

A diferencia de diseños más acabados utilizando computadores de escritorio y software tradicional, la habilidad de dibujar bocetos informales en cualquier momento y lugar –incluso en movimiento- permite a los usuarios descubrir oportunidades para mejoras sustanciales en etapas tempranas del proceso de diseño. Así, se mejora la eficiencia de la productividad. Mediante sketching, el usuario puede emplear símbolos visuales, describir relaciones espaciales [Lank 2004], y intercambiar opiniones [Kenneth 2001] en un medio rápido y eficiente para compartir y discutir ideas complejas [van der Lugt, 2002, Kenneth 2001]. Todo esto, sin embargo, requiere de un soporte para realizar y diagramar bocetos, permitiendo a los usuarios interactuar enfrentándose cara a cara a través de comunicación y explicación de los dibujos a mano alzada realizados simultáneamente. La habilidad de manipular presentaciones gráficas al mantener estos encuentros cara a cara es una manera natural de expresión, crucial para la creación y captura de ideas entre varias personas [Goel 95, van der Lugt 2002, Kenneth 2001].

21

3. Solución Propuesta

A continuación se encuentra la solución planteada para abordar los objetivos propuestos en la sección 1.3. Para ello se han estudiado las necesidades de las aplicaciones colaborativas durante un año, particularmente los requerimientos de las simulaciones participativas. Estas exigencias se resumen a continuación, analizando su solución en el resto de este capítulo.

1. Las actividades colaborativas se basan, principalmente, en la interacción de sus participantes, motivados por un sentido de trabajo conjunto y favorecido por efectos emocionales [Tomsic 2005, Francescato 2006]. La plataforma debe proveer a los participantes con métodos de interacción, ya sea mediante acciones con los dispositivos o a través de encuentros cara a cara. Es por ello que el sistema contará con herramientas para la interacción, tales como el dibujo colaborativo, navegación conjunta, solución colaborativa de problemas e intercambio de elementos, ya sea separados o cara a cara.

2. Existen varias categorías de actividades colaborativas, algunas lideradas por un monitor mientras que otras distribuyen el control de la actividad entre todos los participantes. La plataforma debe brindar la capacidad de administración y monitoreo cuando así corresponda:

a. Algunas actividades requieren la formación de subgrupos dentro del universo de participantes. Para ello, existirá un modo de administrador de grupos, donde el monitor podrá organizar a los participantes en distintos equipos.

b. Algunas actividades requieren que los participantes asuman un rol en particular, ya sea como parte de la actividad (monitor, facilitador, creativo, etc.) o como parte de una simulación (jugar un papel en particular). Cuando así sea, el monitor contará con un modo de asignación de roles.

c. El monitor o administrador de la actividad debe ser capaz de brindar apoyo o evaluación a los participantes. Esto puede gatillarse tras la solicitud de un participante o por decisión espontánea del administrador. Este monitor podrá revisar el estado de trabajo de cada grupo y de cada participante, así como brindar apoyo y evaluación cuando corresponda.

3. Existen varias etapas en una actividad colaborativa, mayoritariamente secuenciales. Normalmente estas etapas son: (a) configuración de la actividad, (b) asignación de roles y tareas, (c) desarrollo de la actividad y (d) análisis y evaluación. Dentro de una misma aplicación, entonces, el sistema debe permitir el avanzar a través de etapas. Para ello, el sistema contará con modos de funcionamiento, los que se activarán manualmente o de forma automática cuando sea apropiado.

22

3.1. Arquitectura de información

Podemos reconocer en [Funaoi 2002] que los mapas conceptuales son la estructura común usada para almacenar y organizar los contenidos en un entorno colaborativo. Un caso particular de ellos son los mapas jerárquicos. Estas estructuras se pueden encontrar en diversos escenarios para apoyar actividades tales como las clases tradicionales, reuniones de trabajo, procesos de diseño, etc. Ellas permiten organizar rápidamente el contenido manipulado, ya que permiten a distintos participantes trabajar sobre cada uno de sus elementos de manera concurrente.

En una clase, a modo de ejemplo, se puede identificar cada concepto como un elemento de este mapa, los que se organizan en jerarquías dependiendo de su profundidad: en una clase de matemáticas donde se enseñará logaritmos, podemos calificar “logaritmos” como el concepto global agregado de alto nivel, luego “logaritmos en base 10”, “logaritmos en otras bases” y “conversión de base en problemas logarítmicos” como subconceptos, así como “explicación”, “ejemplos” y “ejercicios” elementos de cada uno de estos puntos (figura 3.1).

Figura 3.1: Un ejemplo de estructuras jerárquicas en las materias estudiadas en la sala de clases.

Además del manejo de contenidos, desde un punto de vista organizacional las actividades también pueden descritas como estructuras jerárquicas: el curso o actividad raíz se puede organizar en grupos, cada uno ellos compuesto por los participantes que formen parte de él. En el caso de una simulación participativa, en la cual los alumnos asumen roles para llevar a cabo una tarea, podemos reconocer como subestructuras cada uno de los roles y, un nivel más abajo, las tareas asignadas a cada uno de ellos (figura 3.2). Por otra parte, una rama paralela almacenará información acerca de las reglas de la simulación en general (como su duración, eventos programados, entre otros) así como las reglas de las interacciones entre individuos de cada rol.

23

Figura 3.2: Estructura jerárquica de una simulación. Tanto los roles como las reglas de la actividad son subestructuras de la simulación, descritas por otros subelementos.

Son muchos los casos donde podemos reconocer mapas conceptuales jerárquicos en actividades que involucren interacción entre sus participantes. Esta forma de organización permite el trabajo independiente de distintos actores en diferentes áreas del contenido. Es por ello que la arquitectura de información propuesta para este desarrollo considera cada contenido, participante, grupo, rol, así como otros conceptos asociados a aplicaciones particulares, como elementos de un mapa conceptual.

24

3.2. Casos de uso

Realizaremos un análisis sobre los distintos casos de uso necesarios para llevar a cabo un trabajo colaborativo. Especialmente destacaremos aquellos que correspondan a actividades de simulación participativas. Estas interacciones serán la base que nos permitirá seleccionar las interfaces adecuadas a cada usuario.

Inicialmente, reconocemos que cualquier usuario de una aplicación para una actividad colaborativa, incluyendo profesores y alumnos en experiencias educacionales, deben contar con los siguientes casos (figura 3.3):

• Identificarse

• Entrar al sistema

• Salir del sistema

• Leer/revisar el material disponible

• Navegar por el material

• Escribir/modificar/crear nuevo material

Figura 3.3: Casos de uso para usuarios genéricos de la plataforma.

Luego, identificamos aquellas actividades que requieran la intervención de un administrador. En particular, este es el caso de las experiencias educativas, donde el profesor guía y controla la sesión. En estas circunstancias, dicho administrador debe contar con los siguientes casos de uso (figura 3.4):

25

• Crear grupos de trabajo

• Distribuir participantes entre los grupos

• Definir roles

• Asignar roles a grupos o participantes

• Crear tareas relacionadas con una actividad o simulación

• Asignar tareas a grupos, participantes o roles

• Visualizar el estado de avance de la actividad, por grupo o por participante, según cada actividad

• Controlar el estado de la actividad

Figura 3.4: Además de los casos de uso de un usuario genérico, el administrador de la actividad cuanta con diversas funciones posibles.

26

Por otra parte, cuando la actividad se base en una administración centralizada, los participantes sin privilegios de control deberán ser capaces de (figura 3.5):

• Ser notificados de la asignación de grupos, roles o tareas.

• Realizar las acciones asociadas con un rol en particular

• Realizar las acciones asociadas a la resolución de una tarea en particular.

• Interactuar con otros miembros de su grupo

• Interactuar cara a cara con otros participantes siguiendo las reglas dependiente de sus roles previamente definidas

• Consultar su actual estado, así como el de su grupo, en la actividad

• Consultar el estado de otros participantes u otros grupos, dependiendo de la actividad.

Figura 3.5: Los participantes, normalmente alumnos, podrán realizar las acciones resumidas en esta figura. Ellos también contarán con los casos de uso para usuarios genéricos, siempre y cuando corresponda con la actividad y el usuario administrador lo autorice.

En las siguientes secciones se presenta una propuesta que busca satisfacer estos requerimientos de uso, mediante interfaces gráficas adecuadas a cada uno de los actores mencionados.

27

3.3. Interfaces de usuario

Las handhelds han demostrado ser una buena herramienta para actividades colaborativas, debido a su pequeño tamaño y creciente capacidad. Pese a ello, su el reducido tamaño de su pantalla y el uso de teclados virtuales y widgets para ingresar y manipular la información introduce nuevas complejidades en la interacción usuario-dispositivo [Dai 2005]. Para solucionar estos problemas, proponemos el siguiente.

La solución propuesta plantea que casi toda la interacción del usuario, ya sea participante o monitor en la actividad, se realice a través del stylus mediante gestos libres. Esta interacción se analizará e interpretará dependiendo del contexto, interactuando con los conceptos involucrados en el entorno inmediato del gesto. La plataforma incluirá un set de gestos básicos, que faciliten su uso por parte del desarrollador de cada aplicación, sin restringir el número de gestos adicionales que el implementador pueda añadir con el fin de satisfacer las necesidades puntuales de la actividad que se desea apoyar. En los siguientes puntos discutiremos este conjunto de gestos básicos, destacando las acciones que ellos podrían ejecutar.

Cuando el uso de gestos no sea posible o se estimen convenientes métodos alternativos, el programador contará con botones contextuales. La plataforma cuenta con dos clases de estos elementos: los botones contextuales de objetos, que aparecerán en torno al área de los objetos con que se interactúa, y los botones contextuales de modo, que aparecerán en la esquina superior derecha de la pantalla y cuya acción no está relacionada con un elemento en particular sino con el estado de la aplicación en sí. Estos botones o menús también serán activados con clics mediante el lápiz. Finalmente en algunos casos, como en la identificación del usuario, es imprescindible el uso del teclado virtual o reconocimiento de escritura disponible en las PocketPC’s, ya que es necesario el ingreso de palabras tecleadas.

Con el fin de brindar mayor flexibilidad, la aplicación contará con diversos modos, agrupando cada uno funciones necesaria para la instancia desarrollada. Estos modos podrán accederse desde un ícono ubicado en una esquina de la pantalla, con el fin de no interferir en el espacio útil de la pantalla del dispositivo móvil. Pese a que la solución plantea el máximo uso de gestos con el lápiz, estos gestos requieren que el usuario los aprenda y recuerde su acción dependiendo del contexto. Con el fin de reducir la sobrecarga de alternativas, ciertas acciones serán accedidas mediante modos de funcionamiento. Algunos modos de funcionamiento, como el mapa del documento, estarán disponibles para todos los usuarios mientras que otros modos, principalmente de administración de la actividad, estarán disponibles sólo para el monitor.

3.3.1. Representación de los contenidos

Los contenidos son el núcleo de la actividad, ya sea porque representan el resultado de una creación colectiva o porque identifican el cómo cada participante ha interactuado o debe interactuar en la actividad o simulación. Es por ello que el contenido debe tener un rol protagónico en todo instante durante la actividad, permitiendo visualizarle de manera clara y consistente.

28

El tamaño reducido de las pantallas de los dispositivos móviles plantea un desafío en cuanto a cómo debe representarse la información en el espacio. El texto escrito a mano así como los bocetos puede ser comprimido en espacio sin perder legibilidad. Normalmente, los usuarios que escriben en dispositivos móviles lo hacen en un tamaño mayor que el que usarían sobre papel. Es por ello que es necesario encontrar métodos para ahorrar espacio en la pantalla. Una vez que la escritura ya ha sido realizada, se reducirá su tamaño manteniendo la legibilidad.

Tal como ha sido mencionado en el punto 3.1, la estructura de los contenidos es un mapa conceptual. Ello significa que cada contenido pude estar relacionado con otros materiales. Es necesario permitir al usuario visualizar estos contenidos como “elementos” relacionales manipulables. Por ello, cada uno de los contenidos será tratado como uno nodo de este mapa. Se utilizarán etiquetas y vistas reducidas o iconificadas de cada material para representar visualmente su contenido asociado. Ello permitirá manipular, ordenar y re-estructurar el mapa conceptual de contenidos.

3.3.2. Generación de contenidos

La generación de contenidos y material se realizarán a través de sketching4 y gestos contextuales. Aunque el texto escrito a mano pueda utilizar más espacio que el texto tecleado, permite una flexible combinación de bocetos con escritura [Landay 2001, Dai 2005]. De acuerdo a [van der Lugt 2002], los bocetos son una manera rápida de crear diseños que facilita su comunicación a otras personas. La manipulación del material escrito se realizará con el mismo stylus, por lo que será necesario definir gestos particulares que permitan realizar las siguientes acciones sobre el texto generado: selección, movimiento, eliminación, rotación y escalamiento. El sistema proveerá al desarrollador con un conjunto de gestos básicos que permitan realizar las acciones de edición recientemente mencionadas.

La mayoría de las acciones serán realizadas utilizando gestos sobre el área de trabajo. Cada uno de estos gestos constituirá una acción independiente, la que podrá ser activada o no para cada modo de trabajo o aplicación: por ejemplo, varios modos permitirán la creación de material, algunos no dispondrán de creación de contenidos pero si podrán seleccionarlos y arrastrarlos, mientras que otros permitirán la visualización de resultados y no la manipulación de elementos gráficos.

La presente sección describe y discute cada uno de los gestos necesarios para llevar a cabo las acciones para la construcción de contenidos. Una vez creados, gran parte de las veces los materiales generados serán comunicados instantáneamente a los demás participantes. Sin embargo, algunos modos de trabajo restringirán la comunicación del contenido creado, manteniéndolo para uso privado o comunicado solamente a ciertos participantes. Estas determinaciones de privacidad en la comunicación de los contenidos dependerán exclusivamente del diseño y funcionalidad del modo de trabajo o de la

4 Sketch: Boceto (inglés). To sketch: Bocetar, dibujar a mano alzada (inglés). Sketching: Dibujo a mano alzada (inglés)

29

aplicación desarrollada. Por ejemplo, en aplicaciones de diseño colaborativo los participantes compartirán sincrónicamente los diseños desarrollados, mientras que en una aplicación de trabajo grupal colaborativo en la sala de clases cada grupo trabajará privadamente compartiendo los contenidos sólo entre sus miembros y el profesor.

Dibujo y escritura: La principal forma de representar contenidos en nuestra solución es mediante texto escrito y dibujos a mano alzada. Esta manera de construir el material es la más natural para dispositivos basados en interacción mediante el lápiz [Landay 2001, Lank 2004, Hinckley 2005]. Para desarrollar nuevos contenidos, el usuario simplemente debe utilizar el stylus para escribir o dibujar en el área de trabajo de la pantalla de su dispositivo, lo que creará nuevos “trazos” (figura 3.6).

Figura 3.6: Utilizando el stylus, el usuario podrá escribir o realizar dibujos a mano alzada.

Elección de fondo: Algunas aplicaciones, como el diseño colaborativo o la realización de presentaciones de diapositivas, requieren definir una imagen de fondo para cierto contenido. Esta operación se realizará con el gesto de encerrar la pantalla en un rectángulo (figura 3.7.a), lo que gatillará el despliegue de un diálogo genérico de apertura de archivos (figura 3.7.b). Allí el usuario podrá seleccionar cualquier imagen disponible en el dispositivo, incluso fotos recientemente capturadas cuando el dispositivo móvil cuente con cámara incorporada. La imagen seleccionada será asignada como fondo del contenido (figura 3.7.c).

a. b. c. Figura 3.7: Para seleccionar el fondo del contenido, el usuario debe (a) realizar el gesto de encerrar la pantalla y (b) elegir un archivo de imagen. Esto asignará un nuevo fondo de pantalla para el contenido (c).

30

Selección de elementos: Indicar objetos particulares en la pantalla es útil para alterar los contenidos: cierta parte de un dibujo puede ser reemplazada o algún error ortográfico corregido. Además, la selección es importante en la realización de otras acciones, como el desplazamiento de elementos, la asignación de roles o configuración de evaluaciones. Es por ello que hemos dispuesto en nuestra plataforma un amplio conjunto de métodos de selección, donde el programador de una aplicación para actividades colaborativas puede elegir los métodos de selección que más se adecuen al contexto utilizado. Los gestos disponibles para selección son acumulativos, es decir pueden combinarse secuencialmente para realizar configuraciones complejas. Ellos son los siguientes:

1. Selección mediante clic: El usuario podrá seleccionar cualquier elemento de la pantalla haciendo clic sobre él utilizando el stylus (ver figura 3.8). De esta misma forma, el usuario podrá deseleccionar elementos previamente seleccionados.

Figura 3.8: Haciendo clic sobre un trazo, se seleccionarán él y los demás trazos que estén en contacto. En el ejemplo, la letra R queda parcialmente seleccionada, ya que no está completamente conectada con el resto del dibujo.

2. Selección mediante lazo: Debido a que la selección mediante clic puede tornarse engorrosa al enfrentar una situación con múltiples elementos, este método permite seleccionar todos los elementos dentro de cierta área a través de un gesto de lazo. Esto se realiza encerrando el área que se desea con una figura cerrada. Este gesto sólo deberá ser activado cuando no se combine con modalidades de dibujo, ya que el sistema podría confundir los dibujos con el gesto de selección. Para dicho caso, hemos habilitado el siguiente método.

3. Selección mediante lazo doble: Cuando la selección mediante lazo no sea posible, ya que el modo incorpora la posibilidad de escribir o dibujar, se permitirá seleccionar mediante lazo doble. Para ello, el usuario debe encerrar el área a seleccionar con una figura cerrada doble de manera continua (ver figura 3.9). Ello permitirá al sistema diferir entre dibujos de figuras cerradas y el gesto de selección.

Figura 3.9: Múltiples trazos pueden ser seleccionados encerrándoles en una figura doble cerrada. Para ocasiones donde no se utilice escritura o dibujo, podrá utilizarse el gesto de encerrar con una figura simple.

31

4. Selección mediante subrayado: Otra manera de seleccionar conjuntos de elementos utilizando un solo gesto se puede llevar a cabo mediante el gesto de espera y subrayado. Este gesto ha mostrado ser útil para la selección de escritura, en especial para palabras precisas que se desean corregir. El gesto consiste en mantener el lápiz presionado al comienzo de la palabra y esperar que se active el modo de selección por subrayado, indicado con un punto rojo en el lugar de apoyo del lápiz. Cuando ello ocurra, el sistema estará esperando que el usuario continúe el gesto subrayando el área a seleccionar. La figura 3.10 muestra un ejemplo de la utilización de este gesto.

Figura 3.10: Múltiples trazos pueden ser seleccionados con el gesto de selección mediante subrayado. Para ello, el usuario deberá sostener el lápiz en un punto y luego subrayar los objetos deseados.

5. Deselección: Para deseleccionar todos los elementos, volviendo al estado inicial sin objetos seleccionados, el usuario deberá hacer un clic sobre cualquier área vacía.

Copiar y pegar: Múltiples programas actualmente cuentan con las funciones de copiar y pegar, acostumbrando a los usuarios a esta práctica. Duplicar elementos es útil al realizar bocetos complejos, o incluso al escribir listas u otros textos. La plataforma permitirá copiar y pegar mediante dos simples pasos: utilizando los métodos para seleccionar, mencionados previamente, el usuario podrá copiar un conjunto complejo (de uno o más elementos). Es decir, cada vez que el usuario modifique la selección mediante cualquiera de los gestos propuestos, estará definiendo los elementos a copiar. Luego, podrá pegar este conjunto en cualquier parte, incluso en otra página o lugar en el árbol de contenidos, utilizando el gesto de pegar. Este gesto consiste en sostener el stylus presionado de la misma manera que para “seleccionar por subrayado”. Una vez que aparezca un punto rojo bajo el lápiz, el usuario puede levantarlo para pegar los elementos copiados en dicho lugar (figura 3.11). En resumen, tras la espera el sistema aguarda que el usuario (a) subraye elementos para seleccionarlos o (b) levante el lápiz para duplicar la anterior selección.

Movimiento de trazos: Una vez que el usuario ha dibujado ciertos trazos, él puede moverlos primero seleccionándolos y luego arrastrando el lápiz sobre ellos. Esto le permitirá reorganizar no sólo dibujos y escritura, sino todo tipo de elementos en la pantalla.

32

Figura 3.11: El usuario puede seleccionar cualquier elemento utilizando las técnicas de selección propuestas (a y b). Luego, sosteniendo el stylus hasta que se active el modo de selección por subrayado (c). Esta vez, en vez de desplazar el lápiz, lo levantará diferenciándose del gesto de selección. Una nueva copia del elemento copiado aparecerá en la región donde el lápiz se presionó (d).

Escalamiento y rotación: Estas funciones permiten la creación de diseños ricos y diagramas complejos. Por ejemplo, el usuario podría dibujar un boceto con muchos detalles utilizando toda la pantalla del dispositivo, para luego escalar el dibujo a un tamaño menor. Lograr el nivel de detalles en este tamaño final hubiese sido muy difícil de alcanzar. Por otra parte, el usuario podría escribir textos horizontales y luego rotarlos para crear gráficos o diagramas explicativos. En un boceto, elementos repetitivos se podrían duplicar y luego rotar o escalar para alcanzar el dibujo deseado. Para escalar y rotar, el usuario debe primero seleccionar los elementos que quiere alterar. Cuando lo haya hecho, aparecerá un cuadro punteado enmarcando la selección. Al costado derecho del marco se encontrarán dos pequeños handles5: un cuadrado rojo ubicado en la esquina superior derecha, y un círculo azul ubicado abajo del cuadrado. Para escalar, el usuario deberá arrastrar el cuadrado rojo (figura 3.12), y para rotar deberá hacerlo sobre el círculo azul (figura 3.13).

Figura 3.12: Las figuras seleccionadas podrán ser escaladas arrastrando el handler cuadrado rojo, ubicado en la esquina superior derecha de la selección.

Figura 3.13: Las figuras seleccionadas podrán ser rotada arrastrando el handler circular azul, ubicado a la derecha de la selección.

5 Handle: Manilla (inglés). Parte de un objeto que permite manipularlo. En programas de edición es común encontrar handles alrededor de los objetos seleccionados.

33

Eliminación: Para eliminar elementos, se incorporará el gesto de “cruz”. Este gesto se puede utilizar de dos maneras: cuando no haya selección, eliminando cualquier objeto que esté en contacto con el gesto, o de los elementos seleccionados. Si es que uno o más elementos se encuentran seleccionados, el gesto cruz los eliminará, incluso cuando éstos no esté en contacto con los elementos. El gesto “cruz” se debe realizar sin levantar el lápiz, por lo que la figura realmente se parece más a pez, como se aprecia en la figura 3.14.

Figura 3.14: (a) Algunos trazos han sido seleccionado. (b) El usuario dibuja el gesto de cruz conectada, que representa el comando Eliminar. (c) Aparece el feedback de que el gesto ha sido reconocido y aceptado. (d) Los elementos seleccionados son eliminados del contenido.

Tras haber descrito los métodos recientemente explicados, podemos concluir que la solución propuesta permitirá crear bocetos ricos fácilmente: los dibujos se realizarán mediante gestos naturales de sketching, mientras que su edición y manipulación se alcanzará a través de dos pasos: primero, seleccionar los elementos que se desean alterar combinando gestos de selección y, luego, aplicar gestos simples de edición. Las técnicas elegidas para selección, movimiento, escalamiento, rotación y eliminación, así como de copiado y pegado, permiten al usuario crear contenidos detallados a través de métodos sencillos [Denoue 2003].

3.3.3. Árbol jerárquico de contenidos

Una vez que el material escrito o dibujado sea satisfactorio, el usuario deberá ser capaz de declararlo como “conceptos” en el marco de mapa conceptual tratado por la actividad. Cada uno de estos conceptos podrá ser profundizado, o incluir otros conceptos de manera jerárquica. Ello implica que los usuarios podrán “entrar” o “salir” de los nodos, por lo que el sistema debe contar con gestos que permitan “navegar” a través de los conceptos.

Creación de nodos

Como ha sido mencionado, el sistema propuesto permite organizar jerárquicamente contenidos en páginas para resolver el manejo de grandes cantidades de información en la pantalla de tamaño reducido de los dispositivos móviles. Estas páginas estarán asociadas con nodos padres normalmente etiquetados con palabras o dibujos u otro tipo de símbolos, dependiendo del contexto en la aplicación. La aplicación cuenta con diversos gestos para la creación de nodos apropiados para contextos generales, los que pueden ser combinados o adaptados para la creación de aplicaciones colaborativas concretas. Si el programador reconociera la necesidad de nuevos métodos de creación de nodos, podrá hacerlo incorporando nuevos gestos basándose en los incluidos con la plataforma. Los principales métodos para la creación de nodos serán:

c. a. d. b.

34

1. Enmarcar un texto o dibujo: El usuario puede dibujar un rectángulo alrededor de cierto texto o dibujo, normalmente asociado como etiqueta al contenido que contendrá el nodo. Este gesto creará un nuevo objeto rectangular y convertirá los elementos encerrados, tal como se aprecia en la figura 3.15. Este método está orientado en la creación de contenidos jerárquicos, como minutas en reuniones o diseños realizados con un enfoque Top-down6. Adicionalmente, podrá ser utilizado en la creación de tareas, objetos intercambiables u otros elementos útiles en aplicaciones colaborativas educacionales, como se describe más adelante en esta sección.

2. División horizontal de la pantalla: Otro método para la creación de nodos es el subrayar un concepto dividiendo la pantalla. Ello creará un nodo con todo el texto o dibujo que se encuentre entre la línea divisoria y el anterior nodo creado. Este método es muy útil en aplicaciones especiales basadas en listas de conceptos, como la creación de ideas y toma de decisiones [Moran 97].

3. Botones contextuales: Pese a que la plataforma motiva el uso de gestos escritos como principal método de interacción, existen situaciones donde el uso de botones es más cómodo y práctico, u otras donde simplemente el uso de gestos no es posible. Para estas situaciones, el programador puede en ciertas modalidades incorporar botones contextuales de modo, los que se ubicarán en el costado superior derecho de la pantalla.

Figura 3.15: Encerrar trazos con un rectángulo o una figura parcial rectangular crea un nuevo nodo conteniendo los trazos encerrados como su etiqueta.

Navegación a través de los nodos

Una vez que un nodo ha sido creado, el usuario puede acceder a la página asociada a él. Para ello, el sistema cuenta con dos alternativas disponibles: mediante doble clic sobre el nodo o utilizando botones contextuales del objeto. Durante el período de experimentación se reconoció que, pese a que hacer doble clic es el método más natural (debido al modelo mental que han construido los sistemas de manejo de archivo mediante mouse), este gesto puede ser realizado involuntariamente durante la escritura, confundiendo al usuario. Es por ello que, en los contextos donde el usuario puede dibujar o escribir con el lápiz, se cuenta con un método alternativo para la navegación a través de los nodos: Cuando un nodo está seleccionado, se despliega un botón contextual a un costado del nodo. Esto requiere los mismos dos clics que el primer método, aunque de manera ligeramente distinta: el primer clic es para seleccionar el nodo y el segundo para hacer clic sobre el botón.

6Top-Down (inglés): De arriba a abajo. Se refiere a cuando un diseño o esquema describe un problema

desde un alto nivel y paso a paso profundiza el nivel de información.

35

Claramente, la funcionalidad de ingresar a un nodo debe estar acompañada por la opción de regresar a la página padre. Al igual que los métodos para ingresar, la plataforma cuenta con dos alternativas para regresar un nivel más arriba: una opción es hacer doble clic sobre el margen de la pantalla y otra es el ofrecer un botón contextual de modo en la esquina superior derecha. Cuando la aplicación cuente con el gesto de doble clic en el margen, se recomienda que se destaque el borde útil para esta operación, tal como se describe en el punto “Awareness y feedback en la interfaz”.

Una vez que se ha ingresado a una página interior, siempre y cuando la modalidad de trabajo lo permita, el usuario podrá continuar utilizando los mismos modos de escritura, dibujo y edición. Además, podrá crear nuevos nodos, profundizando el árbol jerárquico de contenidos. De esta manera, los usuarios construyen implícitamente un mapa conceptual de la información representada, a través de conceptos jerárquicamente contenidos.

Mapa de navegación

Debido a la complejidad que puede adquirir el árbol jerárquico de la actividad creando contenidos uno dentro de otro, el sistema proveerá de un modo de “mapa jerárquico” que mostrará gráficamente la estructura de elementos y contenidos. Esto permitirá a los participantes, tanto a los alumnos como al profesor en el caso de una aplicación educacional, mantenerse alerta de dónde están en el árbol de contenidos. Esta modalidad es especialmente útil en aplicaciones de diseño y edición colaborativa, así como para la administración de múltiples grupos simultáneos de trabajo.

Figura 3.16: La vista del modo mapa jerárquico muestra un resumen escalado del contenido del documento, incluyendo la posición actual del usuario.

Este modo muestra todos los nodos en el documento, ordenados jerárquicamente. Allí aparece destacado el nodo donde actualmente se encuentra el usuario, informando sobre su ubicación en el mapa. Adicionalmente permite entrar directamente a un nodo sin

36

tener que navegar paso a paso hasta él. Un ejemplo del modo mapa jerárquico se puede ver en la figura 3.16.

Al activar el modo, el mapa de navegación se encuentra reducido para incluir a todos los nodos en la pantalla reducida del dispositivo. Cuando el árbol jerárquico es demasiado grande, algunos nodos miniaturizados podrían tornarse difícil de leer o entender. Es por ello que el modo cuenta con un método para hacer zoom y desplazamiento. En este modo, el usuario puede mantener presionado el stylus y luego arrastrar el lápiz hacia los lados para controlar el zoom, o hacia arriba o abajo para desplazar el área visualizada, tal como se explica en la figura 3.17. De esta manera, con un solo gesto innovador se combinan dos acciones para visualizar y acceder a un árbol jerárquico complejo.

Figura 3.17: Arrastrando el stylus sobre la vista de árbol del documento permite al usuario escalar y desplazar la vista con un solo gesto. Arrastrándolo en diagonal realiza ambas operaciones al mismo tiempo.

Comentarios y notas privadas

En algunos contextos, los usuarios necesitan tomar notas respecto al contenido tratado. Éstas pueden ser opiniones personales, información adicional o preguntas pendientes que deseen hacer al monitor o a otros participantes. Los comentarios y anotaciones se podrán realizar “a un costado de la página”. Esta metáfora nace del mapa mental de que el contenido es una página, que puede ser desplazada o reducida dejando un costado disponible para hacer anotaciones, tal como se observa en la figura 3.18. En particular, la plataforma cuenta con un modo llamado “Notas privadas” donde el usuario puede comentar el contenido actual. Para controlar el tamaño de la página original, basta con “agarrar una esquina” de la página y llevarla hacia el centro de la pantalla. Estando en esta modalidad, el usuario puede también escribir sobre el contenido original, haciendo flechas, símbolos o comentarios sobre los objetos y trazos originales, sin interferir con ellos. Para escribir notas, se pueden utilizar los gestos de escritura, dibujo y edición ya mencionados. Al cerrar este modo, las notas quedan ocultas.

Zoom out Zoom in

Desplazar hacia abajo

Zoom in y desplazamiento

simultáneo

Desplazar hacia arriba

37

Figura 3.18: (a) La página original despliega el contenido a pantalla completa. (b) El usuario arrastra la esquina de la página, escalándola. Esto despliega el espacio “tras la página” para escribir anotaciones. (c) Las notas fuera de la página pueden ser realizadas con los mismos métodos utilizados para la creación de contenido, mediante el uso de gestos con el stylus.

3.3.4. Feedback y awareness

Existen distintas instancias donde el sistema reacciona a ciertos eventos. Estos eventos pueden ser gatillados por acciones del usuario, como gestos con el lápiz, o por otras razones, como la detección de un nuevo participante. Es importante que el usuario entienda las razones por las que ocurren ciertas cosas en la aplicación. Por ejemplo, en una modalidad de edición colaborativa, sería confuso el que algunos dibujos desaparecieran sin explicar el por qué ha ocurrido.

Feedback de gestos

Algunos gestos producen cambios importantes en el estado de la aplicación, ya sea modificando los contenidos o alterando la configuración de la actividad. Un ejemplo es el gesto de cruz, que elimina objetos de la pantalla. Debido a que inicialmente los usuarios pueden desconocer el correcto uso de ciertos gestos, ellos pueden invocarse por error o no ser reconocidos cuando el usuario los realiza incorrectamente. Es por ello que es muy importante el retroalimentar al usuario cuando un gesto ha sido reconocido como tal. Los gestos más complejos y aquellos con efectos más importantes deberían informar al usuario cuando sean gatillados. En particular, la plataforma incorpora sistemas de feedback para algunos gestos y acciones específicos.

El siguiente es el listado de retroalimentación disponible en la plataforma. El programador que utilice la plataforma puede incorporar feedback adicional si así lo estima conveniente.

• Gesto “cruz”: Una vez que el gesto para eliminar ha sido reconocido, el sistema despliega una cruz roja momentáneamente, indicando el sector cubierto por el gesto. Luego desaparece, así como también lo hacen los elementos eliminados. En el caso de que otro usuario realice la acción de borrar, la aparece en todos los dispositivos que están observando dicho contenido, indicando qué usuario realizó la operación. Un ejemplo de esto puede apreciarse en la figura 3.14.c.

38

• Gesto “lazo” o “doble lazo”: Cuando el gesto de selección múltiple ha sido reconocido, el sistema despliega momentáneamente la figura de selección reconocida con un contorno verde. Al desaparecer, los elementos seleccionados reflejan su estado destacando su borde en amarillo.

• Gestos que requieran sostener el lápiz: Como ha sido descrito en 3.3.2, el usuario contará con gestos que requieren mantener el stylus por un momento antes de poder continuar realizando la acción. Es importante el indicar al usuario cuándo ha mantenido el stylus lo suficiente, para lo cual el sistema contará con feedback de cuando ello ocurra: Un punto rojo aparecerá bajo el lápiz indicando al usuario que puede continuar con los gestos.

• “Entrar” y “Salir” de nodos: Cuando el usuario decide entrar a un nodo, este despliega “cuadros de zoom” creciendo reflejando la metáfora de “entrar al nodo”. Lo contrario ocurre al “salir de un nodo” ya que los cuadros de zoom se contraen hasta volver al nodo padre. En el caso que los participantes naveguen los contenidos de manera conjunta, los otros usuarios también serán trasladados a la nueva ubicación y verán los mismos cuadros de zoom que el usuario que gatilló la acción.

Adicionalmente, el sistema contará con un sistema de notificación de eventos locales así como remotos, con el fin de permitir que el programador de cada aplicación pueda interpretar cada tipo de eventos para brindar feedback adicional al usuario, acorde con el objetivo de la actividad apoyada.

Awareness de eventos remotos

Con el fin de evitar dibujos superpuestos, el sistema desplegará avisos localizados cuando otros participantes estén dibujando en el mismo contenido. Aunque esta característica del sistema alertará a los usuarios para que eviten escribir en la misma área, ellos aún pueden realizar dibujos o interactuar en la zona indicada. En la figura 3.19 se aprecia un ejemplo donde tres usuarios dibujan al mismo tiempo sobre el mismo contenido.

Durante la prueba de los prototipos iniciales, se hizo claro que los usuarios requerían feedback del sistema cuando otros participantes realizaban cambios importantes, tales como la eliminación de contenido o navegación. Es por ello que el sistema deberá notificar al usuario cuando otros participantes realicen tales gestos, principalmente para acciones de borrar y de navegación.

Awareness contextual

El sistema deberá brindar awareness al usuario sobre el estado del sistema y la actividad. La aplicación puede llegar a ser muy compleja, debido a la disponibilidad de múltiples etapas o modos de trabajo, o por un elevado número de participantes cooperando simultáneamente.

39

Dispositivo de Gustavo Dispositivo de Felipe Dispositivo de Nelson

Figura 3.19: En el ejemplo, tres usuarios dibujan al mismo tiempo utilizando MCSketcher. Cada uno de ellos está alerta de dónde los otros dibujan, gracias a la retroalimentación de dibujo remoto. Esto ayuda a que los participantes eviten dibujar sobre el mismo espacio.

En prototipos iniciales fue patente la necesidad de indicar al usuario acerca de la modalidad de trabajo en que se encontraba. Es por ello que el sistema deberá indicar mediante un icono el actual modo de trabajo. La figura 3.20 muestra el icono de modo, el que podrá ser utilizado para cambiar de una modalidad a otra cuando ello corresponda, tal como se describe en el siguiente punto. Además, esta figura muestra otros íconos correspondientes a una aplicación colaborativa en particular.

Figura 3.20: El menú ubicado en la parte inferior de la pantalla deberá brindar información al usuario respecto al estado de la aplicación. En el ejemplo se aprecian los íconos para una aplicación de soporte a reuniones de toma de decisiones: el primer ícono permite administrar la sesión, el segundo informa sobre el actual modo y permite cambiar a otras modalidades, mientras que el tercero muestra un gráfico circular indicando cuántos participantes están visualizando la misma página que el usuario actual.

3.3.5. Administración de la actividad

Al igual que la manipulación de contenidos, la actividad también será administrada en base a gestos con el lápiz. Los conceptos serán representados en pantalla mediante íconos y etiquetas. Ellos podrán ser relacionados o jerarquizados a través de drag and drop. Esta técnica es dominada por los usuarios, ya que ha sido ampliamente utilizada en el manejo de objetos, como administradores de archivos en sistemas operativos, programas de diseño, entre otros. En particular, la interfaz sensible al tacto de los dispositivos móviles permite, literalmente, hacer clic sobre un elemento y desplazarlo bajo la presión del lápiz. El gesto de arrastre y asignación estará incluido en la plataforma base y permitirá asignación de grupos y de roles. Adicionalmente, podrá reutilizarse para representar otro tipo de interacciones, como transferencia de elementos, vinculación entre roles, etc.

40

Por ejemplo, la asignación de un usuario a un grupo de trabajo se realizará arrastrando el lápiz desde el ícono del usuario hasta el ícono del grupo. Luego, como fue mencionado en el punto anterior, el monitor podría “entrar” al ícono de grupo para visualizar qué participantes han sido asignados: los participantes se encontrarán literalmente “adentro” del grupo. Asimismo, esta metáfora se extenderá al resto de las acciones necesarias para la administración de la actividad. Si un concepto de “tarea” fue desarrollado con los métodos recientemente descritos, podrá ser asignado a un conjunto de alumnos arrastrándole hasta el ícono de grupo.

La plataforma incluirá los conceptos comunes a la gran mayoría de las actividades colaborativas. Estos serán “participante”, “grupo”, “tarea” y “rol”. Los conceptos adicionales necesarios para cada actividad o simulación deberán ser implementados por el equipo de desarrollo a cargo de cada aplicación en particular.

Tal como ha sido mencionado al comienzo del punto 3.3, existirán diversos modos que permitirán al profesor o monitor administrar la sesión de trabajo. Estos modos agruparán funciones relacionadas, de manera que sea necesario el mínimo número de cambios de modo. Además, si una aplicación requiriera modos adicionales, estos modos pueden ser manipulados e incluso extendidos por el desarrollador de la aplicación particular. Los modos incluidos en la plataforma serán: dibujo libre, creación y asignación de grupos, y mapa jerárquico del documento. Para activar cada modalidad de trabajo el usuario podrá hacer clic en el ícono de modo, el que se aprecia en la figura 3.20.

41

3.4. Estructura de datos

Tal como ha sido mencionado al comienzo de este capítulo, cada elemento en la actividad estará inmerso en una estructura jerárquica. La raíz de dicha estructura será la actividad o, desde un punto de vista más abstracto, la aplicación colaborativa. Ella estará formada por los modos de trabajo, los grupos de participantes y el árbol de contenidos. La figura 3.21 muestra un esquema .

Figura 3.21: La actividad está representada por una metaescructura, compuesta de un listado de modos, un árbol de participantes de dos niveles de profundidad separados en grupos, y un árbol jerárquico recursivo de contenidos, comúnmente organizados por temas.

Para almacenar esta estructura jerárquica, el sistema contará con objetos que permitirán una estructura recursiva. Ello se basará en elementos representables gráficamente, los que llamaremos “dibujables” (drawables). Estos objetos deberán ser serializables7, para poder transferidos a otros participantes o ser almacenados en archivos. Algunos de estos dibujables tendrán la característica de poder almacenar otros elementos en su interior.

Los “dibujables” deberán tener como características principales:

• Su elemento padre: esta información permitiría ubicar el objeto en la jerarquía sin necesidad de redescribir la estructura de hijos del padre. Esto será de principal utilidad cuando los contenidos sean modificados y sus cambios sea transmitida a otros usuarios, los que deben reorganizar su estructura jerárquica para match los cambios generados originalmente.

• Su ubicación en pantalla: ello es necesario para representarlo gráficamente así como para permitir su manipulación.

7 Serialización significa la codificación una estructura de datos como una secuencia de bytes. La acción

contraria es la deserialización, que implica convertir una secuencia de bytes en una estructura de datos válida. Los objetos serializables son aquellos que pueden someterse a serialización, con el fin principal de almacenamiento y posterior recuperación.

42

• Datos intrínsecos a su naturaleza del dibujable: dependiendo de qué represente el objeto, éste podría tener colores, etiquetas, íconos o comportamientos particulares. Por ejemplo, un dibujable asociado a una respuesta dentro de una pregunta deberá almacenar si ella es la correcta o no.

• Información sobre su creación: es importante registrar qué participante realizó que cambios en el contenido o estado de la aplicación, así como cuándo realizó dichas alteraciones.

• Sus elementos hijos, si es que corresponde, u otra información jerárquica: como ha sido mencionado, algunos objetos representarán nodos que podrán almacenar contenidos internamente.

Adicionalmente a la jerarquía asociada a los contenidos descrita explícitamente a través de los nodos, existirá una rama con todos los modos disponibles. Estos modos podrán guardar información adicional necesaria para su correcto funcionamiento. Cada modo deberá definir:

• Su nombre y un ícono que lo caracterice: éste ícono no tan sólo se utilizará para ofrecer el modo en el menú, sino que también permitirá informar al usuario acerca del estado de la aplicación.

• Reglas de interfaz gráfica: en cada modalidad pueden existir diversas maneras de interactuar. En particular, un modo puede habilitar o no los gestos de manipulación de contenidos, además de ofrecer al usuario acciones a través de gestos adicionales.

• Reglas de interacción entre participantes: Ello consiste en definir qué acciones se ejecutarán cuando el sistema reconozca nuevos participantes, usuarios que dejan el sistema, o dos participantes que se encuentran físicamente.

• Reglas de visualización: cada modo podrá recurrir a la manera estándar para desplegar los contenidos en pantalla, desplegarles de otra forma o, incluso, mostrar información contextual acerca de la actividad.

43

3.5. Arquitectura de red

La solución plantea la necesidad de contar con un protocolo de red con las siguientes características:

• Independencia estructural: el sistema debe ser capaz de funcionar bajo una red inalámbrica de infraestructura (basada en routers inalámbricos) o bajo redes inalámbricas ad-hoc (establecida entre los dispositivos sin la necesidad de router u otra infraestructura establecida de antemano). Esto permitirá utilizar el sistema sin exigencias para el escenario, pudiéndose realizar actividades en salas que no cuenten previamente con instalaciones computacionales, en áreas rurales o, incluso, al aire libre.

• Detectar a otros participantes utilizando el sistema: una vez que el usuario active la aplicación en su dispositivo móvil, ésta deberá automáticamte recolectar información acerca de los otros participantes, reglas de la actividad o simulación, así como el estado actual en la generación de contenidos y asignación de tareas y roles.

• Detectar el encuentro entre dos participantes: la plataforma debe identificar cuando dos usuarios se encuentren cara a cara.

• Transmitir contenidos generados dinámicamente, así como también archivos: la plataforma se basará en la sincronía de información entre los dispositivos de cada participante. Ello requiere de un protocolo de comunicación rápido y robusto, el que no sólo permite transmitir los contenidos y acciones generadas dinámicamente, sino que también los archivos utilizados en la actividad.

• Permitir la formación de grupos y restricción al envío de los mensajes: cuando el número de participantes alcanza un tamaño importante, es posible que la red colapse si todos los dispositivos emitiesen mensajes constantemente. Esto demoraría la transmisión o, incluso, causaría la pérdida de información. Es por ello que el protocolo debe ser capaz de configurar grupos de trabajo, donde el envío de mensajes esté restringido a sus participantes y la información sólo sea transmitida fuera del grupo cuando sea explícitamente requerido.

• Distribuir de manera eficiente la información: cómo ha sido mencionado en el punto anterior, en cierto punto el número de mensajes por transmitir puede crecer considerablemente. Éste es el caso, mayoritariamente, del monitor, el que debe recibir las acciones de cada participante, así como ser capaz de transmitir nuevas reglas a todos los usuarios. Ello sobrecargaría el dispositivo del monitor, lo que demanda que esta comunicación sea distribuida.

44

4. Implementación

Este capítulo describe cómo se llevó a cabo el desarrollo e implementación de la solución propuesta en el capítulo 3. Ello comienza con una justificación de la metodología aplicada, para luego explicar en detalle cada uno de las partes del trabajo realizado.

4.1. Metodología de implementación

Tal como ha sido mencionado en la sección 1.4, este proyecto nació con el objetivo de encontrar nuevas herramientas tecnológicas para apoyar el amplio campo de las actividades colaborativas. Ello planteó la necesidad de desarrollar soluciones experimentales de manera incremental. Dicha experimentación no sólo se refería al ámbito computacional, pues la tecnología con que dispuso el trabajo era inicialmente desconocida, sino que las mismas metodologías que se pretendían apoyar nunca antes había sido tratadas de esta manera.

Se determinó que la incertidumbre tecnológica y metodológica debía ser enfrentada con una estrategia de desarrollo en espiral. Este método permitiría enfrentar los riesgos del proyecto de manera paulatina, a medida que se fueran detectando. Poco a poco, los prototipos resolvería las dificultades técnicas encontradas o dudas puntuales respecto a cómo el sistema debería apoyar las actividades colaborativas. Así, en cada ciclo se analizarían los riesgos y desafíos, se propondría una solución enfocada en el problema, para –finalmente- superar la dificultad, generando una plataforma más robusta y madura en cada iteración.

Desde el punto de vista arquitectónico, se decidió que el trabajo se llevaría a cabo mediante programación orientada a objetos, lo que potenciaría la modularidad y extensibilidad de la plataforma. Las funciones comunes a todo el sistema se agruparon en un módulo básico. Además, cada modo y aplicación se desarrolló de manera que encapsulara la funcionalidad adicional en su interior, dejando que las partes de la plataforma trabajasen de manera independiente. Ello permite el activar o desactivar modos o funciones de manera rápida y limpia. A continuación se presentará el resultado de la implementación de cada parte de la plataforma realizando un paralelo con la sección Solución Propuesta.

45

4.2. Diseño del sistema

El diseño global del sistema puede resumirse en el diagrama de la figura 4.1. En él se aprecian los módulos principales de la plataforma.

Los componentes superiores representan al hardware disponible en los dispositivos móviles, a la derecha el módulo de red, abajo la base del sistema y a la izquierda el modo de trabajo activo. Este último componente debe ser adaptado para cada aplicación, puesto que en él residen las reglas de funcionamiento del sistema. Los módulos se comunican entre sí utilizando datos acerca de los participantes, contenidos y gestos.

En los siguientes puntos describiremos la arquitectura utilizada, así como la especificación cada uno de estos módulos, cómo interactúan y cómo pueden ser modificados para lograr objetivos concretos.

4.2.1. Arquitectura

Figura 4.1: Diagrama de módulos principales de la aplicación. Se puede apreciar como los submódulos intercambian información entre si.

Nuestro sistema propone una estructura compuesta desde los gestos desde el usuario, mensajes desde otros participantes, información almacenada hasta el despliegue gráfico. Esta estructura permite ser extendida para administrar la información necesaria para cada modo. Para ello el sistema cuenta con los siguientes módulos:

• SmartCore: es el núcleo del sistema. Administra la aplicación, inicializando los otros módulos y controlando el flujo de ejecución.

• Módulo de comunicaciones: Permite la interacción entre los dispositivos de los participantes, basado en tecnologías inalámbricas IEEE 802.11 e IrDA.

• Módulo de actividad: Agrupa y administra las reglas de funcionamiento de la actual actividad. Aplica el reconocimiento de gestos, representación gráfica y análisis de la información transmitida entre los dispositivos.

46

Con esta configuración, el núcleo de la plataforma activa el sistema de comunicación y activa el modo de trabajo por omisión. Cuando el módulo de comunicaciones recibe un mensaje o detecta el enfrentamiento de otro participante, la información es enviada al módulo de actividad que, según el actual modo de trabajo, interpreta los datos y ejecuta las acciones correspondientes.

La plataforma describe toda la información en objetos que pueden ser compartidos y analizados por cada receptor. Estos objetos han sido denominados “Post Procesables”, puesto que, luego de recibirlos, deben ser procesados en cada dispositivo.

Figura 4.2: Diagrama de clases con las principales subclases de PostProcessables. Los objetos de estos tipos podrán ser comunicados entre los distintos participantes. Cada clase PostProcessable describe el método para reconstruir el elemento una vez recibido, así como las acciones que se cuando el objeto esté listo para utilizarse.

Para ello, el sistema reconstruye cada instancia a partir de la información recibida (ver 4.3.5, Módulo de comunicación) y luego invoca instancia.PostProcess(). Este método realiza los pasos necesarios para (a) restaurar el estado original, (b) incorporar el objeto en el contexto adecuado y (c) ejecutar acciones adicionales propias de la naturaleza del objeto. Además, tal como se ha descrito anteriormente en esta sección, el sistema notificará a cada modo de la aplicación sobre la recepción del elemento, invocando modo.Receive(instancia) para cada modo disponible.

El sistema base incluye un conjunto de objetos que derivan de esta clase raíz. Ellos definen el núcleo de todos los contenidos descritos por la plataforma, y pueden ser extendidos para alcanzar un importante espectro de aplicaciones. Como se aprecia en el diagrama de la figura 4.2, estas clases son Participant, Drawable, FollowMessage, DrawingAwareness y DrawableGrantAccess.

47

Participant

Objeto que representa a un usuario/dispositivo en la actividad colaborativa. Cada vez que un dispositivo se conecta a la red, crea una instancia de esta clase, asignando sus variables con el nombre, dirección IP y otros datos del participante y/o su dispositivo.

Una vez que este objeto es construido, se envía a todos los participantes conocidos. Cuando otros participantes reciben este objeto, lo añaden a la lista de participantes conocidos, la que luego le reenvían al usuario original. Este proceso logra una rápida detección de todos los participantes entre sí, y se describirá con mayor detalle en el punto 4.3.5, Módulo de comunicación.

Drawable y DrawablesContainer

Estos objetos representan el contenido tratado por la aplicación y, por ende, el corazón de la plataforma desarrollada. Drawable es una clase abstracta cuyos elementos representan un elemento dibujable en pantalla. Los miembros más importantes de un Drawable son (a) su objeto padre, (b) su ubicación en la pantalla y (c) quién usuario lo creó. Adicionalmente, los objetos Drawables tienen un extenso listado de propiedades, desde su fecha de creación hasta el color con que se debiera dibujar en pantalla.

Existen tipos especiales de Drawables que pueden contener otros dibujables internamente. Éste es el caso de los PageOwner, subclase de Drawable que contienen una estructura con sus elementos hijos. Esta subestructura es un DrawablesContainer, que almacena una lista con todos los elementos hijos. Esto permite construir estructuras jerárquicas de información. Más adelante, en la próxima sección, profundizaremos acerca de la clase PageOwner y sus derivadas.

48

4.3. Implementación

La programación de esta plataforma abarca un extenso desarrollo, el que no podrá ser descrito cabalmente en este trabajo. Cada módulo de la arquitectura necesaria presentó un desafío en diversas áreas de la informática, tales como interfaces de usuario, reconocimiento de gestos, redes punto a punto, almacenamiento y comunicación de memoria compartida entre puntos, protocolos de transmisión de datos, reconocimiento presencial, etc. Es por ello que a continuación se resumen los puntos más importantes del desarrollo, así como los principales desafíos encontrados.

Tal como ha sido mencionado en la sección “Medotología”, inicialmente el desarrollo se basó en Java para dispositivos móviles, J2ME. Ello permitió un rápido avance debido al alto conocimiento y experiencia que el grupo de desarrolladores para con este lenguaje. Sin embargo, las máquinas virtuales disponibles durante el desarrollo el proyecto no permitían acceder a todas las capacidades de los dispositivos con que se contaba. Es por ello que el proyecto, y en particular la implementación descrita a continuación, fue migrada y finalizada bajo el entorno de desarrollo .NET de Microsoft, utilizando el lenguaje C#, similar en muchos aspectos a Java.

4.3.1. Clases principales

Drawable

La clase Drawable guarda de forma estática el listado de todos los dibujables conocidos por la aplicación. Esto es muy útil para actualizar dibujables o para acciones que se refieren a un dibujable como parámetro. Para ello, esta clase cuenta con un método estático llamado GetDrawable(id, …) que busca el dibujable con el identificador dado.

Como ha sido descrito, la clase Drawable hereda de la clase PostProcessable. En particular, Drawable define el método PostProcess() donde el elemento se inserta en el contexto de su objeto padre. Para ello, los dibujables almacenan el identificador de su objeto padre, al que buscan utilizando el método GetDrawable().

En particular, una vez que el padre ha sido encontrado, PostProcess() invoca a drawable.SetParent(DrawablesContainer), método que reasigna el contenedor del dibujable. Este método también es utilizado por una serie de gestos u eventos, como será descrito en las secciones siguientes.

Drawable es una clase abstracta que reúne todos los elementos que serán representados gráficamente. Las clases que implementen la interfaz propuesta en Drawable deben especificar o sobrescribir una serie de métodos, algunos relacionados con su representación gráfica y otros con su comportamiento ante algunos gestos. Los métodos y miembros más importantes de la clase Drawable se describen a continuación:

1. RegisterDrawable(): Registra el dibujable en diccionario de Drawables disponibles. Esto permite que cualquier modo, gesto u otro evento pueda

49

acceder al dibujable a través de su identificador único. Paralelamente, DeRegisterDrawable() elimina al dibujable del diccionario de Drawables.

2. Rect y Location: Describen la ubicación y tamaño del dibujable en la pantalla.

3. IsVisible(): Responde si es que el dibujable es visible en este momento, consultando variables de privacidad y dependientes del actual modo. La sección 4.3.6 profundizará sobre la descripción de este método.

4. Draw(): Dibuja el objeto. Este método es invocado directamente por el núcleo de la plataforma cada vez que el sistema necesita refrescar la pantalla.

5. Select() y Deselect(): Tal como fue descrito en la sección 3, los elementos en la pantalla podrán ser seleccionados con el fin principal de modificarlos. Para ello, todos los dibujables cuentan con los métodos Select() y Deselect(), que los incluyen o excluyen en la selección.

6. Duplicate(): Crea un nuevo dibujable con las mismas cualidades. Como se describirá a continuación, este método también recorre los hijos del objeto original cuando él sea un PageOwner, duplicándolos.

Un caso especial de los objetos dibujables es la subclase PageOwner, la que brinda a sus objetos la habilidad de almacenar subelementos. Estos objetos están contenidos en la página interna del nodo, permitiendo la creación de árboles jerárquicos de contenidos, donde cada nodo puede contener múltiples nodos, los que a su vez poseen la misma cualidad. Estas páginas son del tipo DrawablesContainer, como se describirá en los siguientes puntos.

Código 4.1: el método rectDrawable.Draw() consulta a cada dibujable si es visible, tras lo cual lo representa en pantalla. Además, podemos reconocer que este método invoca dos veces una subrutina, con el fin de primero dibujar los elementos no seleccionados para luego dibujar los elementos seleccionados. Dibujar posteriormente los seleccionados asegura su visibilidad.

void Draw(Graphics g, float offsetx, float offsety, float zoom) {

Draw(g, offsetx, offsety, zoom, false);

Draw(g, offsetx, offsety, zoom, true);

}

void Draw(Graphics g, float offsetx, float offsety, float zoom, bool selected){

foreach (Drawable d in _Drawables)

if (d.IsVisible() && d.Selected == selected)

d.Draw(g, offsetx, offsety, zoom);

}

50

Un ejemplo de esto es RectDrawable, una de las principales clases que contienen un contenedor interior y otro como etiqueta. Este dibujable, a la hora de representarse, dibuja el rectángulo que denota el área donde está el elemento, para luego dibujar el contenido de su etiqueta, tal como muestra el Código 4.1, donde se aprecia una versión simplificada del método de representación rectDrawable.Draw().

DrawablesContainer

La clase DrawablesContainer representa la contraparte de los objetos dibujables: un DrawablesContainer es el contenedor donde los Drawables se almacenarán y manipularán. Así, cada conjunto de dibujables estará inmerso en un DrawablesContainer, el que representará una página interior de un nodo, los contenidos principales de un nodo secundario o, incluso, el contenedor raíz de la aplicación. Tal como fue descrito en la sección “Arquitectura”, los dibujables con páginas interiores son llamados PageOwners.

Existen casos donde un nodo puede tener más de un contenedor asociado: por ejemplo, los nodos rectangulares para representar conceptos tienen el contenedor correspondiente a su página interna, así como un segundo contenedor relacionado con su etiqueta. La primera de estas páginas es el DrawablesContainer asociado con todo PageOwner, a la que se puede acceder con los métodos propuestos anteriormente, mientras que el segundo contenedor describe el contenido desarrollado dentro de este nodo. La figura 4.3.a muestra un nodo rectangular donde se aprecian trazos a mano alzada como su etiqueta, mientras que 4.3.b muestra el contenido interior de dicho nodo, el que se podrá acceder mediante gestos con el lápiz.

Figura 4.3: (a) Muestra un nodo cuyo contenedor de etiqueta contiene los trazos para formar la palabra “goals”, mientras que (b) expone el interior de dicho nodo, conteniendo subnodos.

4.3.2. Modos de funcionamiento

Los modos de funcionamiento han sido implementados como subclases de Mode. Durante el comienzo de la ejecución, la plataforma realiza una introspección mediante técnicas de reflexión8 para detectar cuales de todas las clases disponibles extienden la

8 Reflexión es la habilidad de un programa de examinar y posiblemente modificar su estructura de alto

nivel durante tiempo de ejecución. Es muy común en máquinas virtuales de lenguajes de alto nivel, como

a. b.

51

clase Mode. Para cada clase detectada, el sistema crea una instancia del objeto y la incluye en la lista de modos disponibles. Cada vez que se invoca al constructor de estos modos, ellos tienen la oportunidad de gatillar acciones especiales. Entonces, por ejemplo, en una aplicación especial, el programador podría cambiar la variable de modo por defecto y definir un nuevo modo inicial.

Una vez que todos los modos han sido instanciados y almacenados, la plataforma activa el modo por omisión. Inicialmente, la plataforma define el modo por omisión como el modo de dibujo. Una versión simplificada del procedimiento para reconocer e instanciar los modos y luego activar el inicial se aprecia en el Código 4.2.

Código 4.2: el método SmartDraw.InitModes().

private static void InitModes() {

Assembly a = Assembly.GetExecutingAssembly();

DefaultMode.Register();

foreach (Type t in a.GetTypes())

if (t.IsSubclassOf(typeof(Mode))) {

Mode theObject = (Mode)a.CreateInstance(t.ToString());

if (!Modes.ContainsKey(theObject.Label))

((Mode)theObject).Register();

}

DefaultMode.EnterMode();

}

Como se aprecia en el código 4.2, para cada modo es invocado el método

modo.Register(), el que le incluye en la lista de modos pero que, cuando es extendido, podría realizar acciones adicionales. Los futuros programadores pueden basarse en el invariante de que el método Register() está asegurado de correr una sola vez.

Por otra parte, cada modo es informado cuando se accede a él, o cuando se abandona. En el código 4.2, la última línea invoca el método EnterMode(). Éste, además de asignar la variable CurrentMode, puede realizar otras acciones. En particular, si el modo es de carácter público y ofrece navegación conjunta, se envía una notificación a los otros participantes informando de dicho cambio. Luego, si cualquiera de los demás participantes se encuentran en otro modo, especialmente denotado para cambiarse de modalidad ante una notificación externa, él también activará el modo en su dispositivo.

La plataforma mantiene al actual modo activado informado sobre los principales eventos del sistema. Así, el modo activo puede reaccionar a dichos eventos de una manera apropiada. Los principales eventos redirigidos al modo activo son gráficos, de interacción con el usuario y de comunicación.

SmallTalk o Java, y menos común en lenguajes de bajo, nivel como C. Particularmente, C# posee capacidades introspectivas de reflexión.

52

Eventos gráficos

Cuando el sistema requiere redibujar la pantalla, pregunta al actual modo si este se encargará de realizar dicho proceso. Esto se lleva a cabo mediante el método mode.DoesOverrideDraw() el que en la clase base responde siempre NO. Si el programador determina que su modo debe hacerse cargo de todo el dibujo en pantalla, debe sobreescribir este método respondiendo SI. Luego, en el caso de que responda positivamente, el sistema pasa el control de la gráfica al modo mediante el método mode.FullDraw(Graphics g).

En caso de que el modo activo no tome el control total de la gráfica del sistema, la plataforma realiza 3 etapas de dibujo: la primera es el pintado del fondo, la segunda es la representación del contenido actual y la última es la información adicional disponible por parte del modo activo y los modos inactivos.

Para el pintado de fondo, la plataforma invoca mode.DoesOverrideBackground() esperando una respuesta. Si ella es positiva, invoca mode.DrawBackground(), mientras que si es negativa invoca drawablesContainer.DrawBackground() para el contenedor de la página actual (ver 4.3.3). Luego, llama a la función drawablesContainer.Draw() para la misma página. Finalmente, invoca mode.DrawAfter() con el modo activo y mode.DrawAfterWhenOff() para cada uno de los otros modos.

En resumen, cada modo puede determinar si toma el control total de la gráfica o si dibuja antes y después del contenido principal. Además, implementando DrawAfterWhenOff() un modo puede dibujar en pantalla incluso si no está activo. Un ejemplo de esto es el modo VoteMode, que dibuja los votos sobre los contenidos incluso cuando está inactivo.

Tal como ha sido mencionado en la descripción de los DrawablesContainers, ellos son capaces de dibujar su contenido en distintas escalas y/o con desplazamiento. En particular, cuando la pantalla principal es dibujada por el sistema (es decir, cuando el modo activo respondió FALSO a mode.DoesOverrideDraw()) ello permite el poder representar el contenido principal de manera escalada y/o desplazada. Por el contrario, en algunos modos de funcionamiento desarrollados especialmente por los programadores de aplicaciones colaborativas, puede existir la necesidad de limitar dicha capacidad, por lo que el modo puede sobreescribir el método mode.HandlesCoordinatesWithOffset(). Cuando un modo no sea capaz de administrar coordenadas alteradas, su contenido se representará siempre con una escala del 100% y centrado en el origen.

Eventos de interacción con el usuario y de navegación

El reconocimiento de gestos es la principal manera de interacción con el usuario en nuestra solución. Tal como ha sido descrito en múltiples ocasiones en este trabajo, la plataforma incluirá un conjunto de gestos incorporados que permitirán al programador de nuevas aplicaciones colaborativas contar con un sistema de reconocimiento preexistente, así como brindarle las herramientas para construir nuevas formas de interactuar.

53

Nuestra plataforma filtra toda acción del lápiz, sintetizándola, con el fin de canalizar las acciones al modo activo. Estas acciones son el inicio del contacto entre el lápiz y la pantalla, el movimiento de éste contra la pantalla y cuando el usuario levanta el lápiz. Cuando el usuario apoya el stylus, el sistema consulta al modo activo si administra o no dicha acción. Cuando no lo haga, el sistema registra el resto del movimiento del lápiz como un arreglo de puntos, enviándolos de forma paralela y continua al modo activo. De lo contrario, cuando el modo no tome la administración del movimiento sobre la marcha, se graficará en pantalla el trazo parcialmente dibujado. A medida que el movimiento se va realizando, la plataforma va incrementando un dibujable del tipo Stroke, que representa el trazo completo dibujado hasta el momento. Este tipo de Drawable será descrito en el próximo punto, Reconocimiento básico de gestos.

Finalmente, cuando el usuario levanta el lápiz, el trazo generado desde el inicio hasta el final del movimiento es entregado al modo actual para que lo analice y gatille las acciones necesarias. La figura 4.4 muestra un ejemplo que ilustra estas 3 etapas para el modo de dibujo, en dos escenarios distintos: un gesto que inicia sobre un elemento es interpretado como "mover el elemento", mientras que el mismo gesto iniciado en un área limpia generara un nuevo trazo para el contenido.

Figura 4.4: (1) Muestra el resultado de (1.a) apoyar, (1.b) arrastrar y (1.c) levantar el lápiz, produciendo un trazo (1.d). (2) Muestra el mismo gesto, (2.a) iniciando el apoyo del lápiz sobre un elemento seleccionado es interpretado como desplazamiento del elemento (2.b y 2.c), el que finalmente ve alterada su posición cuando el gesto finaliza (2.d).

Debido a la capacidad del sistema de presentar vistas reducidas o desplazadas, la interpretación de gestos debe adaptarse a dichas transformaciones gráficas. Es por ello que, cuando un modo sea capaz de administrar coordenadas modificadas (respondiendo TRUE a mode.HandlesCoordinatesWithOffset()), los puntos de acción del lápiz deben traducirse al punto relativo a la proporción y desplazamiento de la vista actual.

Otra de los eventos informados al modo actual son los cambios de página realizados por algún gesto y otro evento. Cuando un gesto implique entrar o salir de un nodo, así como cualquier modificación en la posición actual dentro del árbol de contenidos, el modo activo recibirá dicho evento mediante la llamada al método mode.PageChanged(). De la misma manera que los otros eventos administrables, originalmente esta llamada no produce ninguna reacción y puede ser alterada por nuevos métodos con el fin de lograr la funcionalidad apropiada en cada modalidad.

1.a. 1.b. 1.c. 1.d.

2.a. 2.b. 2.c. 2.d.

54

A modo de ejemplo, así como descripción de las capacidades de la plataforma, revisaremos el modo VoteMode, incluido en la plataforma básica. Primero, se puede ver en el Código 4.3 como este modo extiende la clase Mode, añadiendo variables internas necesarias para su funcionamiento e implementando su constructor.

Código 4.3: el modo VoteMode extiende la clase Mode, definiendo variables internas para su funcionamiento, además de definir su constructor. En él, define los modos de seguimiento así como su etiqueta e ícono para el usuario. Además, establece las reglas de interpretación para el evento MouseUp.

public class VoteMode : Mode {

...

private static Hashtable VotedDrawables = new Hashtable();

private static ArrayList KnownVotes = new ArrayList();

public VoteMode() {

SharingMode = SmartDraw.SharingModes.Sharing;

FollowingMode = SmartDraw.FollowingModes.FollowNode;

Label = "Vote";

Icon = new Bitmap(a.GetManifestResourceStream("vote.png"));

}

...

bool AnalyzeMouseUp(DrawablesContainer dc, Stroke sg) {

if (!VoteAgainstGesture.AnalyzeMouseUp(dc, sg))

if (!VoteForGesture.AnalyzeMouseUp(dc, sg))

if (!SelectionGesture.AnalyzeMouseUp(dc, sg))

return false;

return true;

}

...

}

El modo VoteMode redefine particularmente el método AnalyzeMouseUp(…). Debido a que este modo no define AnalyzeMouseDown() o AnalyzeMouseMove(), los puntos dibujados serán acumulados en un elemento del tipo Stroke, tal como fue descrito en el punto anterior. Una vez que el gesto finalice cuando el usuario levante el lápiz, el método AnalyzeMouseUp(…) será invocado pasándole dicho Stroke como parámetro. Entonces, el trazo sg será utilizado en las distintas llamadas de cada uno de los posibles gestos que el sistema pretende reconocer.

Cuando una de estas llamadas responda verdadero, se detendrá el proceso de reconocimiento, puesto que dicho gesto, previo a contestar positivamente, ejecutará las acciones pertinentes. Este paradigma para el reconocimiento y aplicación de acciones se describirá en el punto subsiguiente. En este modo, podemos reconocer la siguiente cadena de acciones: si no reconoce que el usuario vota en contra de un concepto, y luego no reconoce que el usuario vota a favor de un concepto, y luego no reconoce que el usuario está realizando un gesto de selección, entonces responde que no fue capaz de administrar

55

el trazo sg. De lo contrario, contesta verdadero. Ello significa que uno de los tres gestos evaluados ejecutó su acción y luego respondió positivamente.

Eventos de comunicación y de enfrentamiento físico

Adicionalmente a todos los eventos ya mencionados, existe una categoría de sucesos que, a diferencia de los anteriores, dependen del entorno en el que el usuario y su dispositivo participan. Estos eventos ocurren cuando algún otro participante envía mensajes especiales o cuando un participante se enfrenta a otro cara a cara.

Como ha sido descrito en el punto “Arquitectura”, toda la comunicación de información se basa en una clase común llamada PostProcesables. De ellos heredan los Drawables, elementos dibujables y protagonistas en nuestro sistema. Sin embargo, otros objetos también son PostProcesables. En particular, varios de los modos incluidos en la plataforma definen sus propios mensajes internos como PostProcesables. Por ejemplo, la notificación de que un usuario ha votado se envía como un VoteMessage, el que es procesado una vez que se recibe.

Pese a que los mismos objetos PostProcesables sean responsables de procesarse una vez recibidos, todos los modos son notificado de cada elemento recibido. Por omisión, los modos ignoran la totalidad de estas notificaciones, pero es posible sobreescribir el método Receive(PostProcessable obj) con el fin de que dicho modo reaccione ante la llegada de un objeto, sin la necesidad de modificar la implementación de PostProcess() de la clase del elemento recibido. Un rápido ejemplo, que se profundizará en la sección 4.4, es la recepción de un objeto de la clase Participant: existen algunos modos que cuando son notificados del ingreso de un nuevo participante crean un dibujable asociado al nuevo usuario detectado, permitiendo una serie de acciones mediante gestos al administrador de la actividad.

Otro evento notificado es el enfrentamiento con otro participante. Cuando el usuario alinee su dispositivo con el de otra persona, estos se reconocerán mediante detección infrarroja. Luego, el sistema notificará al modo activo sobre esta nueva configuración física: mode.EngangeParticipant(Participant p) será invocado permitiendo que el modo actual realice acciones pertinentes al enfrentamiento. En particular, la definición por omisión de todos los modos es ignorar este evento, pero los programadores de nuevas aplicaciones pueden sobreescribir esta función en sus modos con el fin de administrar esta situación, gatillando las acciones necesarias. Puntualmente, y como será descrito en el punto 4.4, la aplicación para simulaciones participativas desarrollada para ejemplificar el uso de esta plataforma basa su sistema de negociación entre participantes mediante detección de enfrentamientos cara a cara.

4.3.2. Representación gráfica

Tal como ha sido descrito previamente, nuestro sistema se apoya en objetos representables gráficamente. Ellos almacenan su ubicación en la página y contenido, además de describir en su implementación los métodos para dibujarles. A la hora de

56

refrescar la pantalla, el sistema invoca el método DrawablesContainer.Draw(…) de la actual página visualizada, la que puede ser accedida con el método estático GetCurrentPage().

Cada vez que un contenedor DrawablesContainer requiere ser dibujado en pantalla se le entregan ciertos parámetros respecto al offset y zoom con que debe ser representada. Esto permite fácilmente implementar visualizaciones escaladas y sistemas de scroll. Para la página actualmente visualizada, el método Draw, se invoca en el origen de la pantalla y con un zoom de 100%. Otros dibujables, como los nodos, pueden además invocar el método Draw para su etiqueta, desplazado para calzar sobre el rectángulo y reducido para ahorrar espacio en la pantalla.

Para realizar dicha representación, cada DrawablesContainer posee un listado de todos los Drawables que contiene. Para cada uno de ellos, consulta la visibilidad a través del método drawable.IsVisible() para luego invocar drawable.Draw() con los mismos parámetros de offset y zoom que el contenedor recibió. Por su parte, cada Drawable recibirá estos parámetros, a los que añadirá su posición relativa y se dibujará. Una versión simplificada de este método se aprecia en el Código 4.4.

Código 4.4: el método drawablesContainer.Draw() dibuja la base de su área con los colores de su participante creador. Luego delega el dibujado de su etiqueta a la clase DrawablesContainer a través de Label.Draw(), método que se explicará en el siguiente punto.

void Draw(Graphics g, float offsetx, float offsety, float zoom)

{

Rectangle r = new Rectangle((int)(offsetx + (Rect.X) * zoom),

(int)(offsety + (Rect.Y) * zoom),

(int)(Rect.Size.Width * zoom),

(int)(Rect.Size.Height * zoom));

if (Selected)

g.DrawRectangle(Drawable.SelectedPen, r);

g.FillRectangle(Creator.LightBrush, r);

g.DrawRectangle(Creator.DarkPen, r);

Label.Draw(g, offsetx + (int)((Rect.X) * zoom),

offsety + (int)((Rect.Y) * zoom), ContentZoom * zoom);

}

57

4.3.3. Reconocimiento básico de gestos

El reconocimiento de gestos se basa en el análisis de elementos del tipo Stroke. Tal como fue descrito en el punto 4.3.2, a medida que el usuario arrastre el lápiz por la pantalla bajo un modo que no administre dichos eventos la plataforma construirá e incrementará un dibujable del tipo Stroke que reunirá todos los puntos que forman el movimiento del stylus. Así como ejemplifica el Código 4.2, las distintas modalidades verificarán el Stroke generado frente a un conjunto de gestos, los que revisarán el trazo y responderán verdadero o falso. En caso positivo, y antes de responder, el gesto deberá realizar las acciones asociadas a dicho reconocimiento, aunque presentaremos ejemplos mostrando que aquello no es siempre necesario.

De la misma manera que un modo reacciona ante los eventos de interacción de usuario, los gestos implementados poseen métodos que analizan los momentos iniciales, intermedios y finales de cada gesto, llamados AnalyzeMouseDown(), Analyze-MouseMove() y AnalyzeMouseUp(), los que reciben como parámetro el trazo temporal generado por el usuario. Cuando una de estas funciones estáticas es invocada por cada una de las clases de los gestos correspondientes, ellas pueden responder FALSO si es que el trazo temporal no calza con la descripción interna del gesto, o realizar alguna acción en particular y luego responder VERDADERO, para declarar que el gesto fue reconocido y detener la cadena de reconocimiento.

Los elementos del tipo Stroke, además de los métodos comunes a todos los dibujables, poseen un conjunto de funciones que permiten acceder a cada uno de sus puntos, en particular el inicio y final. Es de especial utilidad el método stroke.Touches(), el que permite consultar si el trazo dado está en contacto con un rectángulo en particular. Esta función facilita al programador la matemática necesaria para, por ejemplo, recorrer el listado de Drawables presentes y encontrar cuáles han sido tocadas por el trazo. Como caso particular, podemos destacar que los gestos de selección por subrayado y de eliminación utilizan esta importante funcionalidad.

Debido a la alta resolución de las pantallas sensibles al tacto de las handhelds, la cantidad de puntos reconocidos en un solo trazo puede ser enorme. Cuando ello ocurre, el análisis de figura dibujada puede tornarse engorroso y lento. Es por ello que la plataforma otorga a los programadores herramientas de compresión y análisis angular de los trazos generados. Ello permite reducir Strokes con cientos de puntos a un tamaño razonable, además de poder reconocer los ángulos relativos entre cada parte del trazo.

El algoritmo de compresión se basa en dos parámetros: ángulo máximo requerido y cercanía proporcional con los vecinos. Para cada punto del trazo, calcula el ángulo que forma con ambos de sus vecinos, así como la distancia a ellos. Los puntos que no satisfagan los parámetros de entrada son eliminados. Si en la iteración, algún punto fuese eliminado, entonces el proceso se repite nuevamente, ya que se formaron nuevos pares de vecinos que ahora podrían ser seleccionador para eliminación.

58

Un ejemplo del uso de compresión y análisis angular puede apreciarse en el reconocimiento del gesto cruz: éste recibe un Stroke como parámetro y le aplica una compresión de 90º. Esto eliminará todo punto que genere ángulos mayores o iguales a 90º entre sus vecinos. Por ende, si el trazo representaba una cruz con exceso de puntos, éste se simplificará hasta quedar con tan solo 4 vértices, tal como muestra la figura 4.5. De lo contrario, en el caso de quedar con otra cantidad de puntos, podemos rechazar la hipótesis de que el trazo correspondía a una cruz. Cuando obtenemos los 4 puntos esperados, es muy fácil corroborar si ellos se encuentran en esquinas opuestas y cruzándose el primer y último segmento cerca del centro de la figura. Cuando ello ocurra el sistema retornará verdadero, puesto que ha encontrado una cruz. En cualquier otro caso, el sistema responderá falso.

Figura 4.5: (a) Muestra el trazo mientras es dibujado por el usuario. (b) Una vez que el usuario levanta el stylus, el objeto Stroke generado es analizado por cada gesto candidato en busca de alguno que lo reconozca. (c) El gesto CrossGesture realiza una compresión de 90º sobre el trazo, permitiéndole reconocer que (d) sólo quedan 4 puntos y el segmento inicial intersecta el final cerca del centro.

Como ha sido mencionado previamente, cada modo espera que el gesto que responda verdadero al analizar el trazo dado invoque una serie de acciones tras el reconocimiento. Pese a ello, la plataforma incluye una serie de gestos que sólo reconocen formas en particular, sin realizar acción alguna. El motivo de ello es que estos gestos pueden ser utilizados, a su vez, por otros que sí realicen acciones. Esto se debe a que una misma figura o movimiento del usuario puede representar diferentes acciones: el gesto cruz en modalidad de dibujo representa borrar, mientras que en modalidad de votación significa dar un voto negativo. Los gestos pasivos incluidos son: el gesto cruz, el gesto tic, el gesto de arrastrar un elemento, el gesto de dibujar un rectángulo, y los gestos de clic y doble clic.

4.3.4. Generación de contenidos jerárquicos mediante gestos con el lápiz

Tal como ha sido propuesto en la sección 3 los contenidos son generados mediante movimientos simples de escritura y dibujo libre, junto con edición basada en gestos sencillos. Cada modo debe definir si acepta o no la generación de nuevos contenidos: por ejemplo, el modo principal de sketching debe permitir la escritura o dibujo, así como la manipulación de los trazos generados, mientras que el modo de votación no debiese permitir la creación de nueva información.

Para incorporar la capacidad de creación y edición de contenidos en un modo, la implementación cuenta con una serie de gestos que, al ser incorporados en la etapa de

a. b. c. d.

59

interpretación de eventos de usuario, permiten añadir la funcionalidad necesaria para construir nuevos contenidos.

Los gestos descritos a continuación han sido concebidos para satisfacer los requisitos planteados en el punto 3.3.2, y su reconocimiento se realiza en siguiente orden de prioridad:

• MoveGesture: gesto que desplaza los trazos o elementos seleccionados con el movimiento del lápiz. Actúa y responde verdadero cuando el inicio del gesto (MouseDown) se realiza sobre cualquier elemento seleccionado.

• LassoGesture: gesto que selecciona todos los elementos encerrados por la figura dibujada. Actúa y responde verdadero cuando los puntos de la figura repiten dos veces la misma forma.

• CutGesture: gesto para eliminación de los elementos seleccionados o alcanzados por la figura dibujada. Actúa y responde verdadero cuando, al simplificar la figura en 90º, sólo quedan cuatro puntos que describen una cruz (figura 4.5).

• CreateRectNodeGesture: gesto para la creación de un nuevo nodo, que encierra todos los trazos al interior del rectángulo dibujado, convirtiéndoles en la etiqueta del nodo creado. Actúa y responde verdadero cuando la figura dibujada se asemeja a un rectángulo completo o parcial, y existen trazos en su interior.

• StrokeGesture: gesto que convierte el trazo temporal pasado como parámetro en parte del contenido definitivo. Actúa y responde verdadero cuando el trazo temporal tiene un tamaño superior a un mínimo aceptado configurable.

• SelectionGesture: gesto que añade o remueve elementos de la selección. Actúa y responde verdadero cuando el trazo temporal corresponde a un clic (tamaño muy pequeño) y ha sido realizado sobre algún contenido de la página actual, o cuando existe una selección y el clic ha sido realizado sobre un área vacía.

Cabe destacar que estos gestos de edición pueden ser complementados con otros necesarios para aplicaciones especiales. En particular, gestos para rotación y escalamiento pueden ser incorporados a la cadena de reconocimiento cuando el modo deba ofrecer dichas funcionalidades al usuario. Con el fin de ejemplificar el uso de este paradigma para el reconocimiento, se puede apreciar el Código 4.5, que muestra la cadena de reconocimiento del modo de dibujo, incorporado los gestos recientemente descritos, y el Código 4.6, que muestra la implementación del método CreateRectNode-Gesture.AnalyzeMouseUp().

60

Código 4.5: implementación del método AnalyzeMouseUp() del modo de dibujo.

public class DrawingMode : Mode {

...

public bool AnalyzeMouseUp(DrawablesContainer dc, Stroke sg) {

if (!MoveGesture.AnalyzeMouseUp(dc, sg))

if (!LassoGesture.AnalyzeMouseUp(dc, sg))

if (!CutGesture.AnalyzeMouseUp(dc, sg))

if (!CreateRectNodeGesture.AnalyzeMouseUp(dc, sg))

if (!StrokeGesture.AnalyzeMouseUp(dc, sg))

if (!SelectionGesture.AnalyzeMouseUp(dc, sg))

return false;

return true;

}

...

}

Código 4.6: Versión simplificada de la implementación del método CreateRectNodeGesture.AnalyzeMouseUp(). Se puede apreciar cómo el gesto delega el reconocimiento de la figura rectangular al gesto pasivo RectGesture. El método drawablesContainer.Offer() transfiere al RectDrawable dado todos sus dibujables del tipo dado cuando estén en contacto con el dicho rectángulo, respondiendo verdadero si es que algún dibujable fue transferido.

public class CreateRectNodeGesture : Gesture {

...

public static bool AnalyzeMouseUp(DrawablesContainer gc, Stroke oSg) {

if (!RectGesture.AnalyzeMouseUp(gc, oSg))

return false;

RectDrawable rg = new RectDrawable(oSg.Rect.Size);

if (!gc.Offer(rg, typeof(FreeWriting)))

return false;

return true;

}

...

}

61

4.3.5. Módulo de comunicación

Tal como ha sido descrito en la sección 3.5, la plataforma requiere que el módulo de comunicación cumpla con una serie de funciones para la transferencia de información necesaria en el sistema. Para ello se ha desarrollado, junto a otros participantes en el proyecto, un subsistema de comunicación que cumpla con los requisitos ya mencionados. Esta solución reúne diversos protocolos de transferencia de datos, como TCP y UDP sobre IP junto con IrDA. Las principales características del subsistema de comunicaciones son:

• Independencia estructural: la solución desarrollada está basada en protocolos de comunicación TCP y UDP, las que pueden funcionar sobre direcciones de red estáticas y dinámicas. En particular, cuando los dispositivos móviles se comunican a través de una red ad-hoc establecida entre ellos, la solución es capaz de transferir exitosamente los datos necesarios, sin la necesidad de contar con una infraestructura pre-existente.

• Detectar a otros participantes utilizando el sistema: utilizando broadcasting UDP, cada dispositivo publica una señal con la que da aviso de su disponibilidad en la red. Consecuentemente, todos los dispositivos se encuentran continuamente esperando la detección de señales de disponibilidad de otros handhelds. Una vez que dicho mensaje ha sido recibido, se establece una conexión punto-a-punto. A través de esta conexión directa, ambos se envían mutuamente el listado de otros dispositivos detectados, acelerando el proceso de reconocimiento topológico. Esto disminuye el tiempo de descubrimiento, ya que no es necesario que cada dispositivo descubra y se presente uno por uno a los otros mediante broadcasting UDP. Una vez que dos dispositivos han establecido su conexión, esporádicamente se enviarán mensajes keep alive9 dando aviso de la validez de la conexión.

• Sincronización inicial de información: cada vez que el sistema detecta un nuevo participante, el módulo de comunicación envía un evento al núcleo de la plataforma. Éste resume la información serializada de todo el contenido público generado, anexando todos los datos internos que cada modo requiera comunicar, y lo envía al nuevo participante detectado. De la misma manera, el nuevo participante realizará estas mismas acciones, asegurando la simetría de la información entre ambos participantes. Cuando esto se extiende a que cada participante hace lo mismo con cada uno de los detectados, se construye una memoria compartida común, la que será descrita en mayor profundidad en el punto 4.3.6 en esta misma sección.

• Detectar el encuentro entre dos participantes: utilizando los puertos infrarrojos, la plataforma es capaz de reconocer la cercanía y enfrentamiento cara a cara de dos participantes. Cada un período de tiempo dado, el sistema pregunta

9 Keep alive: Mantener con vida (inglés). Mensaje que, al ser recibido, valida la conexión. Cuando una conexión no ha recibido mensajes de este tipo tras un período establecido de tiempo, la conexión caduca.

62

al puerto IrDA que realice una detección de puntos infrarrojos disponibles para comunicación. A través de este procedimiento, cuando dos dispositivos están alineados, ellos comparten sus respectivos códigos de identificación. Este código es el mismo utilizado por el sistema de reconocimiento IP descrito previamente, por lo que la plataforma compara el identificador con los participantes anteriormente reconocidos. Cuando encuentre una coincidencia, entonces marcará al actual participante enfrentado con tal estado, y realizará el envío de los eventos de enfrentamientos descritos en la sección 4.3.3.

• Transmitir contenidos generados dinámicamente, así como también archivos: el módulo de comunicaciones simplifica el envío de información a todos los participantes. Basta con sólo invocar el método node.SendObject(Object o) para que éste lo serialice y envíe a cada uno de los participantes. Es el mismo módulo de comunicación de los otros dispositivos que se encargará de recibir el mensaje binario y decodificarlo en el objeto originalmente enviado. Luego, este elemento será recibido por la plataforma y procesado cuando así corresponda. De la misma manera, el módulo cuenta con el método node.SendFile(String path) que coordina y realiza la transferencia de un archivo con cada uno de los participantes en la actividad. Mediante estas simples funciones, transparentes desde la perspectiva de la plataforma así como para los programadores de nuevos aplicaciones, el sistema es capaz de transferir contenidos desarrollados dinámicamente o cargados desde archivos a todos los participantes, sin que futuros desarrolladores deban implementar su distribución nuevamente. Por otra parte, cuando la transferencia deba ser realizada de manera privada, es decir con entre sólo dos participantes, ambos métodos han sido sobrecargados para establecer una comunicación simple sin transmitir la información al resto de los participantes. Ellos son node.SendObject(Participant p, Object o) y node.SendFile(Participant p, String path).

• Permitir la formación de grupos y restricción al alcance de los mensajes: una de las funciones más importantes del módulo de comunicaciones es la habilidad para formar grupos dentro del universo de participantes activos. Para ello, la aplicación almacena el listado de dispositivos detectados junto con un identificador del grupo al que cada uno pertenece. Inicialmente, los participantes no pertenecen a ningún grupo. Luego, cada vez que se invoca el método node.JoinGroup(String groupId) desde algún modo producto de un gesto o procesamiento de un mensaje, la plataforma modifica la variable que identifica el grupo del que forma parte, y envía un mensaje de bajo nivel a todos los dispositivos conocidos, con el fin de que estos también actualicen sus datos. Entonces, cuando cualquier mensaje necesita ser emitido por la plataforma o sus modos utilizando node.SendObject(), el sistema de red sólo comunicará esta información a los participantes que formen parte del mismo grupo. Como excepción, cuando una actividad posea un administrador o monitor, los métodos de comunicación también enviarán el mensaje a este usuario especial. El siguiente punto en esta sección describe con mayor detalle el cómo, utilizando este módulo de comunicaciones, la plataforma saca partido a esta capacidad.

63

• Distribuir de manera eficiente la información: Cuando el número de participantes crece, o la información que es necesario compartir alcanza un tamaño significativo, pueden producirse sobrecargas durante el envío de la información. Por ejemplo, cuando un participante carga un archivo donde almacena contenidos generados previamente, debe comunicar uno a uno todos los dibujables y datos adicionales leídos. Es por ello que el módulo de comunicaciones funciona distribuyendo el trabajo pendiente: cuando un elemento debe ser compartido, éste es comunicado a sólo dos participantes dentro del universo pendiente. Además, el resto de los usuarios es separado en dos mitades, las que son enviadas a los participantes elegidos previamente. Entonces, ellos deben repetir este proceso enviando solamente a dos usuarios y distribuyendo el saldo restante. Pese a que transmitir cada mensaje requiera de más pasos e involucre más interacción entre los participantes, permite que ante cantidades importantes de información, el sistema equilibre la carga y brinde una comunicación más fluida y pareja. De esta manera, el trabajo de comunicación es distribuido equitativamente entre todos los integrantes de la actividad.

El módulo de comunicaciones descrito ha sido mayoritariamente desarrollado previamente, como memoria de Magíster, y posteriormente mejorado, como memoria de título de Ingeniería, por otros participantes en el proyecto: Sebastián Uribe y Jaime Hernández respectivamente. Ellos han sido los responsables de implementar las funciones de independencia de redes de infraestructura, reconocimiento de participantes en la red, envío de objetos y archivos, creación de grupos y comunicación de mensajes distribuida. Las funciones de sincronización de información y de reconocimiento presencial de enfrentamiento fueron desarrolladas como parte del proyecto por el autor del presente trabajo, Felipe Baytelman.

4.3.6. Memoria compartida

Los contenidos tratados en cada sesión están almacenados principalmente en el árbol jerárquico originado a partir del DrawableContainer raíz del documento, así como en un arreglo estático que resume todo la información en el documento, Drawable.KnownDrawables. En ellos, los objetos dibujables representan la información por sí mismos, ya que forman parte de escritura o simbolizan parte del contenido de otra manera. Además, cada modo posee en sus variables internas información adicional que también constituye parte del contenido. Un ejemplo de esto es la información sobre votaciones, la que está almacenada como VoteMessages dentro del modo VoteMode.

Cuando el usuario escribe o realiza un boceto, cada trazo que dibuja se convierte en un Drawable almacenado en la página actual y en el listado de todos los Drawables. Esto se logra mediante los modos drawable.SetParent() y drawable.Register(), respectivamente. Una vez que un elemento está asociado a una página particular y ha sido registrado, puede ser compartido con los otros participantes, utilizando el método SmartDraw.Share(newDrawable). Ello comenzará la cadena que serializa el objeto, los transmite a cada participante y, luego, es deserializado y postprocesado en cada dispositivo remoto.

64

Es en este postproceso que el dibujable recibido es reconstruido y ubicado de manera simétrica a su posición original en el dispositivo del creador. Ello permite que, continuamente, los nuevos elementos del contenido sean comunicados a todos los participantes entre sí, manteniendo un universo común.

Similarmente, cuando un usuario realiza una modificación de un elemento, dicho cambio puede ser compartido utilizando el mismo método Share(). En esta oportunidad, en vez de realizar la comunicación del objeto completo, se enviará sólo la información modificada. Para ello, el sistema cuenta con una clase especial de mensajes, DrawableUpdateMessage, la que permite transmitir la mínima cantidad de información necesaria para realizar la actualización de los cambios aplicados.

Hasta ahora, los dos métodos de transferencia de información aseguran la sincronía de los nuevos contenidos y sus cambios. Debemos entonces considerar una manera de sincronizar la información previa a la creación de nuevos contenidos y sus modificaciones. Si aseguramos el que en un comienzo, todos los participantes posean un contenido único común, la metodología de enviar todos los nuevos elementos y sus modificaciones aseguran una memoria común constante. Es por ello que, en un comienzo, los participantes se enviarán mutuamente toda la información que ellos posean. Tal como ha sido revisado recientemente en el punto 4.3.5, cuando el sistema detecta un nuevo participante, toda la información actual es serializada y enviada, con el fin de crear un estado común entre ambos dispositivos. Como esto es realizado por cada par de usuarios, se crea una red inicial de comunicación que unifica todos los contenidos individuales en uno común. Desde este punto, entonces, basta sólo con enviar los cambios, sin la necesidad de compartir la totalidad del estado del documento común.

Sin embargo, existen casos donde la memoria compartida tiene diferentes alcances. Por ejemplo, cuando se ha establecido el trabajo grupal, donde los alumnos están separados por grupos, la memoria común de cada equipo es local y no necesariamente es compartida con miembros de otros grupos. Tal como fue descrito en 4.3.5, cuando un usuario es parte de un grupo, el sistema sólo enviará los cambios a los demás miembros de su conjunto y al administrador, cuando exista uno. Entonces, como cada grupo mantiene una memoria local con sus miembros y adicionalmente la comparte con el administrador, este último conocerá la memoria global del sistema, ya que recibirá los cambios de cada una de las memorias locales de cada grupo.

4.3.7. Administración de grupos

El sistema ha sido diseñado para apoyar principalmente actividades educacionales, donde el número de usuarios en la actividad obligará a dividir el universo de participantes en grupos. Ello permite una mejor comunicación entre sus integrantes, una colaboración más fluida y una evaluación y control más sencilla por parte del profesor o monitor. Durante el desarrollo de nuestro proyecto, una serie de escenarios presentaba la necesidad de formar grupos de manera dinámica. Es por ello que se implementó un modo de formación y administración de grupos, con el cuál el administrador de la actividad, desde su handheld y mediante gestos del lápiz, podría configurar la distribución de los participantes dentro de la actividad.

65

El modo representa a cada participante mediante un ícono y una etiqueta con su nombre, los que aparecen en la pantalla principal del modo de organización de grupos cada vez que un nuevo participante es detectado por el sistema de comunicaciones. De esta forma el administrador observa en su pantalla una serie de elementos que representan, cada uno de ellos, un participante. Estos objetos han sido implementados como ParticipantDrawables, y heredan de la clase Drawable.

Una vez que todos los participantes se han conectado, el administrador puede crear varios grupos y comenzar a distribuir los participantes. Haciendo clic en un botón contextual de modo, ubicado en la esquina superior derecha, puede crear un nuevo grupo, el que es representado por un rectángulo de color con un ícono de carpeta. Este rectángulo muestra la pantalla común del grupo creado, inicialmente vacía ya que ninguno de sus integrantes ha desarrollado ningún dibujo o contenido. Este elemento ha sido implementado como GroupDrawable, y extiende la clase PageOwner. Repitiendo el proceso de creación de grupos, el administrador puede generar la cantidad de grupos que estime necesaria.

Utilizando los gestos de selección y movimiento descritos previamente, el administrador puede seleccionar y reorganizar a los participantes en su pantalla. En particular cuando arrastra un ParticipantDrawable sobre un GroupDrawable, el gesto reaccionará como una asignación de pertenencia. El ParticipantDrawable desaparecerá del espacio común y será incluido al interior del GroupDrawable. Repitiendo este proceso, el administrador puede distribuir los participantes en los diversos grupos creados. La figura 4.6 muestra un ejemplo de la pantalla de asignación de grupos.

Figura 4.6: El modo de administración de grupos permite la creación de nuevos grupos y la asignación aleatoria de participantes utilizando botones contextuales, y la asignación individual mediante gestos de arrastre con el stylus. La figura muestra como el administrador está asignando el participante “Guillermo” al grupo 2 arrastrándolo sobre su cuadro.

Para revisar qué participantes ha asignado a cierto grupo, el administrador puede seleccionar el GroupDrawable y “entrar” a su interior utilizando el botón contextual que

Botón para crear nuevos grupos

Botón para asignar los participantes disponibles de manera equitativa entre los grupos

Participantes pendientes

Utilizando el gesto de arrastrar su ícono, el administrador puede

asignar un participante a un grupo de manera

individual

66

aparece junto al rectángulo del grupo. Cuando realice esta acción, la pantalla desplegará los ParticipantDrawables previamente asignados al grupo seleccionado. Para remover un participante del grupo, devolviéndolo al espacio común, puede utilizar el gesto de “cruz” que reubicará a los ParticipantDrawables en su ubicación original, listos para ser reasignados.

Cuando un participante haya sido asignado a un grupo, el administrador generará un mensaje GroupMessage y lo enviará al participante involucrado. Éste, al recibir el mensaje, invocará internamente node.JoingGroup(). De esta manera, el sistema de comunicaciones asignará el grupo de comunicación específico, informará con mensajes de bajo nivel al resto de los participantes sobre esta nueva configuración reconfigurando la topología de bajo nivel y limitará el flujo de información a los participantes que formen parte del mismo grupo.

Además del mensaje de asignación de grupo, el administrador comparte la memoria local del nuevo grupo con el nuevo integrante, con la finalidad de que comparta el mismo estado que el resto de los miembros del grupo. Es importante destacar que esto es necesario ya que los contenidos desarrollados previo al cambio fueron sólo compartido por los miembros originales del grupo y con el administrador, y los demás participantes fueron ajenos a dichos contenidos y modificaciones debido a la configuración del sistema de comunicaciones: Una vez que dos o más participantes forman un grupo, la comunicación de todos los cambios y creación del contenido realizados por ellos será transmitido de manera restringida exclusivamente a los miembros del grupos y al administrador de la actividad (ver 4.3.5, Módulo de comunicación).

67

4.4. Integración en una aplicación para simulación participativa

El objetivo de este trabajo es el de desarrollar una plataforma que permita la realización de software para apoyar simulaciones participativas, entre otras aplicaciones colaborativas. Es por ello que se ha desarrollado una aplicación particular que, utilizando la plataforma, permite llevar a cabo una simulación de producción e intercambio que induce a los alumnos participantes a adquirir conocimientos respecto a cómo afecta el prestigio y el nivel de información en las relaciones comerciales.

La simulación modelada dividirá el curso en dos grupos: los participantes que juegan el rol de fabricante/vendedor y los que cumplen el rol de consumidor/comprador. Los fabricantes/vendedores tendrán una o más “fábricas de productos” que cada cierto período de tiempo crearán una nueva instancia de su producto asociado. Por otra parte, los alumnos consumidores/compradores tendrán una o más necesidades por productos, las que deberán satisfacer adquiriéndolo de un vendedor que lo ofrezca.

El núcleo del aprendizaje radica en que cada vendedor fabrica productos de distinta calidad y precio, representada por su duración en el tiempo. El fabricante conoce cuánto duran en promedio sus productos, y debe decidir cuánto será el tiempo de duración que ofrecerá cuando promocione sus productos entre los clientes. Por ejemplo, un productor puede fabricar casas que en promedio duren 200 segundos, y decidirá publicitarlas con una duración de 180 segundos, con el fin de no defraudar a sus clientes si es que estas fallan antes de los 200 segundos. Otro productor con la misma capacidad de fabricar casas, pero esta vez de menor duración (150 segundos), podría promocionarlas con la misma expectativa de vida que el primero, 180 segundos, con el fin de aumentar las ventas de los productos (si ofreciese casas de 150 segundos o menos, los consumidores elegirían las casas vendidas por la competencia). De esta manera, ambos fabricantes ofrecerían, desde el punto de vista del comprador, el mismo producto. La diferencia comenzará a ser patente cuando los consumidores del segundo fabricante comiencen a percatarse que sus casas duran menos que lo prometido, disminuyendo el prestigio del vendedor y, directamente, influyendo en sus futuras posibilidades de negocio.

Cada vez que un producto caduque con una vida igual o superior a la que el vendedor ofreció, el cliente dará un punto a favor al prestigio del productor. Por el contrario, si es que el producto caduca antes de los esperado, el comprador podrá acercarse al vendedor y devolverle el producto. Si es que el productor acepta esta devolución, debe rembolsar el dinero pagado al cliente, lo que le otorga un punto de prestigio positivo. Si no acepta la devolución, entonces, el producto desaparece y el vendedor obtiene un punto de prestigio negativo.

Poco a poco, cada cliente irá obteniendo distintas apreciaciones de cada productor. Dos compradores pueden compartir sus experiencias, encontrándose, permitiendo complementar el conocimiento que tienen de cada vendedor. Este conocimiento acerca del prestigio de los productores será útil a la hora de adquirir un

68

producto: durante la negociación, el indicador de prestigio mostrará al comprador cuan confiable es cada vendedor, influyendo en su decisión.

4.4.1. Casos de uso

Esta aplicación representa un prototipo básico con el fin de demostrar las capacidades de la plataforma desarrollada en el presente proyecto. Es por ello que la aplicación cuenta con un conjunto limitado de casos de uso, los que permiten llevar a cabo la simulación participativa de manera simple y directa. Los casos de uso de la actividad para cada uno de los actores (administrador, vendedores, consumidores) se pueden apreciar en la figura 4.7:

Figura 4.7: Casos de uso para un prototipo básico que demuestra las capacidades de la plataforma.

Los anteriores casos de uso brindan al administrador la capacidad de configurar rápidamente la actividad. Sin embargo, son múltiples los casos de uso que podrían ser añadidos con el fin de complementar las funcionalidades disponibles: por ejemplo, pese a que la aplicación cuente con gestos para la asignación de una fábrica de productos o de una necesidad de productos, no cuenta con gestos para revocar dicha asignación. Tampoco existen métodos para dar formalmente inicio y fin a la actividad. Entonces, queda propuesta el análisis e implementación de casos de uso que mejoren la usabilidad de esta aplicación.

4.4.2. Modos de administración, simulación y evaluación

A grandes rasgos, la aplicación se compone de tres modos de configuración de la actividad, el modo principal de la aplicación y un modo de resultados y evaluación. A continuación revisaremos dichos modos, explicando qué modificaciones o desarrollos adicionales a los incluidos en la plataforma fueron necesarios.

69

Modo de configuración de productos

Este modo permite al administrador crear bocetos y escritura mediante los gestos descritos anteriormente. A diferencia del modo de creación de contenidos genérico, este modo incorpora el uso del gesto rectangular para crear una nueva familia de productos. Una vez que la familia de productos ha sido creado, este aparece iconificado al costado inferior de la pantalla, tal como se muestra en la figura 4.8.

Las familias de productos podrán ser asignadas como fábricas o como necesidades a los vendedores y compradores respectivamente. Cuando una familia de productos sea asignada a un vendedor en particular, éste recibirá una fábrica con características particulares generadas aleatoriamente a partir de una distribución normal basada en los valores definidos por el administrador. Para configurar estos valores, el administrador puede utilizar el gesto “doble clic” sobre el ícono de cada familia de producto para acceder a la pantalla de configuración de sus valores estadísticos. En esta pantalla, puede configurar cuales serán el valor y duración promedio de las fábricas del producto, así como la varianza que será utilizada a la hora de asignar una fábrica a un vendedor.

De esta forma, por ejemplo, el administrador podrá definir que las fábricas del producto “casa” generan instancias con una duración promedio de 3 minutos y una varianza del 10%. Entonces, si a un productor se le asigna dicha fábrica, la esperanza de vida de sus productos podrá ser un valor generado mediante una distribución normal N(3, 0.3). Supongamos que la fábrica produce “casas” con una duración promedio de 3.2 minutos: Entonces las “casas” construidas por el vendedor tendrán una duración dentro de una distribución normal N(3.2, 0.3). Así, no sólo las fábricas variarán unas de otras, sino que también lo harán los productos generados por una misma fábrica.

Figura 4.8: Pantalla de diseño de familias de productos. Utilizando el gesto de contorno rectangular el administrador puede crear nuevas categorías de elementos. Se puede apreciar los íconos de los productos previamente concebidos.

70

Modo de asignación de roles

La siguiente pantalla permite al administrador separar el curso en vendedores y consumidores. En esta pantalla, los participantes son representados por ParticipantDrawables, pequeños íconos con el nombre de cada alumno. Además, la pantalla está dividida en tres franjas: verde, blanco y amarillo. El área verde está etiquetada como “Vendedores” y la amarilla como “Compradores”. Sólo es necesario que el administrador arrastre los íconos de los participantes hacia un costado u otro para asignarles un nuevo rol. Para ello, el modo cuenta con el gesto de movimiento, modificado para realizar la asignación cuando el participante sea dejado en el área correspondiente a un rol en particular (ver figura 4.9).

Figura 4.9: (izquierda) El administrador arrastra el ícono de un participante hacia el área de asignación de fabricantes. Luego, (derecha) el participante ha sido asignado bajo el rol de fabricante.

Modo de asignación de fabricación y necesidad de productos

Una vez que las familias de productos han sido diseñadas y los roles han sido asignados, el administrador puede distribuir los distintos productos entre los participantes. En el modo de asignación de productos, aparecen los íconos de los participantes al costado asociado a su rol y los íconos de familias de productos. Basta con que el administrador arrastre un ícono de producto sobre un productor/vendedor o sobre un consumidor/comprador para asignarle la habilidad de fabricar o la necesidad de adquirir: automáticamente aparecerá en la pantalla del vendedor el ícono de la fábrica de productos o en la pantalla del consumidor el ícono de necesidad de producto.

Modo de simulación

Una vez que el rol y los productos han sido asignados, cada participante puede ver en su dispositivo el estado de la simulación. Vendedores y consumidores interactúan con su dispositivo mediante pantallas similares. La pantalla de los vendedores está dividida en tres áreas: arriba se encuentra el área de negociación, a la izquierda se encuentran las

71

fábricas y sus datos de producción, y a la derecha se ubican los productos disponibles para la venta. La pantalla de los consumidores también tiene tres regiones: arriba comparte el área de negociación, a la izquierda se encuentran sus requisitos pendientes, y a la derecha se ubican los productos adquiridos actualmente consumidos. En ambos casos, el área de negociación despliega un indicador de prestigio: la pantalla de los vendedores muestra su prestigio a nivel general mientras que la de los consumidores muestra el prestigio del vendedor con que están negociando.

Los productores/vendedores pueden observar los datos de producción junto al ícono de cada fábrica de productos. Al costado de cada ícono, se despliega el tiempo restante para la producción del siguiente ítem, el precio del producto y el tiempo de vida ofrecido junto con la esperanza real del producto. De la misma manera que el administrador puede configurar una familia de productos, el vendedor puede hacer doble clic para modificar el precio del producto y el tiempo de vida ofrecido mediante una ventana similar a la del administrador.

Una vez que un producto ha sido creado, el vendedor puede ofrecerlo a un comprador. Para ello, debe buscar un participante que tenga la necesidad por el producto, enfrentarse cara a cara alineando sus dispositivos y realizar el gesto “ofrecer producto”. Dicho gesto consiste en mover el ícono del producto hasta el área de negociación, la que reflejará el estado de negociación con la etiqueta “Negociando con …”.

Figura 4.10: (a) Luego de enfrentarse cara a cara, el participante “vendedor” arrastra uno de los íconos de producto al área de negociación. (b) El producto aparece en el sector de negociación del dispositivo del “cliente”, desde donde dicho participante lo arrastra hacia la zona inferior de su pantalla. (c) Entonces, la transferencia se realiza, desapareciendo el

72

producto del dispositivo del productor y actualizándose los valores de dinero y puntaje en ambas pantallas.

Por otra parte, el comprador al enfrentar al vendedor podrá observar el prestigio que el vendedor tiene, junto a los productos ofrecidos. En particular, el ícono del ítem mostrará su precio y la duración ofrecida por el vendedor. Si el consumidor decide no realizar la compra, sólo basta que abandone al productor y busque otro proveedor del bien. En caso de querer realizar la compra, éste debe arrastrar el producto ofrecido desde el área de negociación hacia el centro de la pantalla. A través de este gesto, se realizará la transferencia del bien al comprador además del valor del producto al vendedor. Un ejemplo del proceso de enfrentamiento y negociación se puede apreciar en la figura 4.10.

Modo de resultados y evaluación

El modo de resultados presenta una pantalla donde se exhiben el ranking de los participantes con mejores resultados: los vendedores con mayores ingresos y los compradores que obtuvieron mayor valor versus dinero gastado. La primera lista está acompañada del indicador de prestigio obtenido por el vendedor, mientras que la segunda muestra cuánta información manejaba cada comprador.

4.4.3. Herramienta de apoyo educacional

Permitiendo el desarrollo de la actividad y apoyándose en la información obtenida, el profesor es capaz de explicar a los alumnos la relación entre los valores obtenidos. Los indicadores secundarios, prestigio y cantidad de información, deberían ser proporcionales al resultado obtenido por los participantes, mostrando a los alumnos la relación entre prestigio versus éxito comercial, y entre información del mercado versus valor obtenido. Así, mediante el uso de una simulación participativa generada a partir de la plataforma desarrollada, los alumnos perciben de manera práctica y motivante los objetivos educacionales de la actividad.

73

5. Resultados

A lo largo de un año y medio de trabajo, se ha construido una plataforma capaz de apoyar diversas actividades colaborativas. Durante este período, y como parte de la investigación y prueba de la plataforma, se ha desarrollado múltiples aplicaciones para las áreas de apoyo a reuniones, toma de decisiones, diseño colaborativo, evaluación grupal y simulaciones participativas. A continuación, revisaremos las experiencias más significativas obtenidas durante el desarrollo de dichas aplicaciones. La plataforma desarrollada ha sido utilizada en múltiples aplicaciones para apoyar actividades colaborativas, mayoritariamente como herramienta de investigación.

5.1. Sistema como plataforma para aplicaciones de trabajo colaborativo

5.1.1. Prototipos llevados a cabo

NOMAD

NOMAD es una herramienta de apoyo a reuniones [Zurita 2006], basada en la primera versión de nuestra plataforma. Ella fue desarrollada en Java y ejecutada sobre J9. Fue la primera oportunidad para utilizar el sistema desarrollado en una aplicación real. Esta herramienta incorporó habilidades de votación, colaboración sincrónica y asíncrona, motivando la creación y desarrollo de toda la implementación necesarias para lograrlas. Ello permitió evaluar la usabilidad de un primer sistema completo y poderoso, reconociendo los problemas y falencias relacionados con la funcionalidad ofrecida así como de la implementación en sí.

Tabla 5.1: Problemas reconocidos durante la evaluación heurística de NOMAD

Problema Severidad Aspecto Tema Distribución lenta de la información serio colaboración sincronización Confusión en la sincronización serio colaboración sincronización Selección se confunde: A veces se selecciona cuando realmente no se quiere seleccionar

serio interfaz gestos

No escribe bien: Es necesario repasar las letras. serio interfaz trazos No se puede borrar todo cosmético interfaz gestos Pantalla se queda chica al escribir a mano serio interfaz trazos El trabajo se ve cortado serio colaboración sincronización Pueden empezar a escribir en el mismo lugar cosmético colaboración sincronización No se sabe quién hizo tal cosa cosmético interfaz gestos A veces se hacen nodos indeseados crítico interfaz gestos Sin querer se entran a nodos, lo que provoca que el grupo se mueva, perdiendo el contexto

serio interfaz trazos

74

La evaluación fue realizada por un grupo de expertos en el área de aplicaciones colaborativas, encabezado por Pedro Antúnez. Esto permitió obtener un análisis exhaustivo, profundo y preciso sobre las principales virtudes y defectos de la aplicación. En dicha evaluación, los expertos reconocieron las capacidades de la plataforma, así como su facilidad de uso y rápido aprendizaje de los gestos incorporados. Sin embargo, durante el análisis heurístico, detectaron una serie de problemas o debilidades de la aplicación. A continuación se encuentra la tabla 5.1, donde se dichas dificultades.

NOMAD 2

Una de las grandes limitaciones de la primera versión de NOMAD estaba relacionada con la incapacidad de la máquina virtual para reconocer la máxima resolución de los dispositivos con pantallas VGA. Además, era ineficiente a la hora de realizar dibujos en la pantalla, consumiendo una gran cantidad de recursos. Este sobre consumo producía saltos en el sistema de reconocimiento del lápiz, generando trazos poco definidos prohibitivos para una escritura fluida y dibujos preciso.

Por estos motivos, se determinó la necesidad de re-implementar la plataforma y, en particular, el sistema NOMAD bajo la arquitectura .NET basándose en el lenguaje C#. Esta reconstrucción dio espacio a la incorporación de cambios y nuevas funcionalidades, e incluso motivó el surgimiento de nuevas aplicaciones, descritas en los próximos puntos.

A raíz del análisis obtenido tras la evaluación de la primera versión de NOMAD, se determinó la necesidad de realizar una serie mejoras para solucionar los problemas reconocidos en la versión inicial de dicha aplicación. Dicho análisis, motivó una serie de propuestas para corregir y mejorar tanto la aplicación como la plataforma, permitiendo a esta última perfeccionarse y evolucionar en la que sería la base de sistema alcanzado como resultado de este trabajo. De estas sugerencias, podemos reconocer las que fueron incorporadas a la plataforma, mientras que otras fueron postergadas para trabajo futuro. De todas las mejoras realizadas, las principales relacionadas con la plataforma fueron:

• Incluir un medio para coordinar las áreas donde cada participante está escribiendo: Esto se implementó incorporando retroalimentación a los demás participantes (sección 3.3.4).

• Utilizar otro método para ingresar y salir de los nodos: tal como fue mencionado en 3.3.3, los modos donde los usuarios pudiesen realizar dibujos o escribir utilizan un método alternativo de navegación basado en botones contextuales de objeto.

• Desplegar en el tope de la pantalla un indicador de la posición actual: Al ingresar a un nodo, su etiqueta es mostrada como fondo de la parte superior de la pantalla, tal como se aprecia en la figura 4.3.

• Desplegar animaciones cuando se realizan acciones remotas, como navegación y manipulación de contenidos.

75

• Una vez creado un nodo, disminuir el tamaño de la escritura para ahorrar espacio.

• Mejorar la usabilidad del modo de vista de árbol: se eliminó la información irrelevante e incorporó un gesto innovador para navegar por él.

Sistema de apoyo a la toma de decisiones

Karl Strasser desarrolló una aplicación de apoyo a la toma de decisiones, diseñado para aplicar la metodología propuesta por [Kaner 2005]. Dicho sistema se construyó a partir de la plataforma evolucionada tras el desarrollo de NOMAD 2. Utilizó un conjunto híbrido de gestos, contando con algunos de los incorporados originalmente en la plataforma así como otros desarrollados exclusivamente para esta aplicación. Este trabajo se representa la memoria de título de su autor y se encuentra en proceso de publicación.

En la actividad de toma de decisiones, cada usuario escribe en su dispositivo ideas sobre el tema en discusión. A través de gestos de división horizontal, permite a cada participante definir nuevas ideas de manera individual. Luego, al entrar el modo de discusión grupal, los participantes comparten sus ideas para discutir verbalmente las ventajas de una sobre otras. Finalmente, en el modo de convergencia, determinan qué ideas son aceptadas por el grupo, descartando o fusionando las secundarias.

Adicionalmente, de manera experimental, Kart Strasser utilizó exitosamente la plataforma para desarrollar aplicaciones de dibujo, incorporando características de color y grosor del lápiz, así como aprovechando las capacidades de rotación y escalamiento incluidas en el sistema original. Otro experimento consistió en construir un modo para definir tablas, al estilo hoja de cálculo, el que de manera exclusiva utilizaba gestos con el lápiz para escribir contenido, crear nuevas filas y columnas, así como reorganizar las celdas dentro de la tabla.

MCSketcher

MCSketcher [Zurita 2006] es un sistema que permite el diseño colaborativo frente a frente, basado en dibujo libre utilizando dispositivos interconectados mediante redes ad-hoc. Su objetivo es el apoyar bocetos preeliminares in-situ, permitiendo a los diseñadores intercambiar ideas a través de bocetos incluso sobre fotografías recientemente tomadas de los objetos o locaciones acerca de los que se realiza el trabajo.

MCSketcher se basa en el módulo genérico de dibujo, anexando capacidades de escalamiento y rotación. Además, incorpora navegación mediante doble clic, la que permite crear nodos ubicados espacialmente, y no relacionados con una etiqueta. Incluye, también, los gestos para manipulación de imagen de fondo, lo que permite realizar bocetos sobre imágenes o fotografías, convirtiéndose en una útil y rápida herramienta para el trabajo en terreno en dispositivos con cámaras integradas.

76

Sistema de asignación de grupos y evaluación para la sala de clases

Este sistema utiliza el modo de administración de grupos para formar conjuntos de alumnos en la sala de clases. Luego, el profesor puede activar el modo de diseño de problemas, donde mediante gestos simples de dibujo puede –sobre la marcha- escribir el encabezado de un problema y diversas alternativas para él, seleccionando cuál es la correcta (en el caso de una respuesta única) o cuál es la secuencia correcta (para preguntas de secuencia). El profesor puede crear cuantas preguntas desee, o cargarlas desde un archivo previamente desarrollado. Finalmente, utilizando el modo de asignación de pregunta, puede arrastrar el ícono de cada problema sobre el ícono de un grupo, asignándolo. El profesor puede asignar un mismo problema a varios grupos, así como múltiples problemas a cada grupo.

Por su parte, los alumnos ven en su dispositivo los problemas que le han sido asignados. Seleccionando uno de ellos, pueden desplegar la pregunta y responder utilizando los gestos tic o cruz, mediante el lápiz. Finalmente, en el modo de resultados, el profesor puede ver un resumen en forma de tabla, donde se muestran los resultados de cada grupo y sus preguntas asignadas. El profesor puede hacer clic sobre una celda para visualizar la respuesta del grupo para la pregunta seleccionada.

5.1.2. Posibles aplicaciones

Sistema para presentaciones mediante bocetos con feedback en línea

La plataforma puede ser utilizada para construir una aplicación que soporte el desarrollo de presentaciones. Éstas pueden estar basadas simplemente en bocetos a mano alzada, o a partir de diapositivas exportadas desde programas como Microsoft PowerPoint u OpenOffice. Por su parte, los alumnos podrían seguir la en una pantalla gigante o proyección. Incluso, si el sistema se adaptase para funcionar en computadores de escritorio, podría utilizarse directamente en una pizarra electrónica.

Los alumnos, además de seguir la presentación en sus dispositivos, podrían reproducir las diapositivas anteriores e incluso la manera en que el profesor fue construyendo los contenidos. También podrían minimizar el tamaño de la presentación, utilizando gestos similares a los expuestos en el punto “notas privadas”, permitiéndoles enviar comentarios y preguntas al profesor de manera sincrónica. El profesor, mientras da su disertación, visualizaría un pequeño símbolo que indicaría el que hay comentarios o preguntas pendientes. Entonces, activaría el modo de “preguntas y respuestas” donde, una a una, revisaría los comentarios y preguntas del público.

Método de formación de grupos basado en reconocimiento de enfrentamientos

Es posible construir un método que reorganice los grupos basado en la distribución espacial de los alumnos. A diferencia del modo de formación de grupos, es factible desarrollar un subsistema que, mediante el reconocimiento de enfrentamientos cara a cara entre dos participantes, altere la configuración de los grupos sin la necesidad

77

de que un coordinador o administrador intervenga. Para ello, bastaría crear un modo de formación de grupos alternativo que reaccionara ante los encuentros uniendo uno de los participantes al grupo del otro: El usuario perteneciente al grupo más pequeño entre los dos dejaría su grupo para unirse al grupo del otro. Además, un usuario podría decidir dejar su grupo, con el fin de encontrar otro más pequeño o simplemente formar un nuevo conjunto. Este modo propuesto es perfectamente compatible con el resto de la plataforma y podría reemplazar modularmente el actual modo de configuración de grupos.

78

5.2. Sistema como plataforma para simulaciones participativas

5.2.1. Prototipos llevados a cabo

Como fue descrito en la sección 4.4, la plataforma fue exitosamente empleada para generar una aplicación de soporte a una simulación participativa puntual relacionada con la enseñanza del impacto del prestigio en las relaciones comerciales. Dicha aplicación aprovechó las capacidades de la plataforma para la creación rápida de bocetos, la incorporación de nuevos gestos de lápiz basados en gestos de reconocimiento pasivos, la detección de enfrentamientos entre participantes así como la creación de objetos transferibles basados en los objetos genéricos del sistema.

5.2.2. Posibles aplicaciones

Tal como ha sido mostrado en la literatura [Colella 2000, Andrews 2003, Zurita 2004, Klopfer 2005] las simulaciones participativas consiguen positivos resultados en la sala de clases escolares. Algunos trabajos muestran la aplicación con alumnos universitarios sin utilizar tecnologías móviles [Alonzi 2000, Truscott 2000, Marburger 2005]. Entonces, podemos sugerir como posibles campos de acción para la creación de nuevas aplicaciones de soporte a simulaciones participativas las siguientes áreas del conocimiento:

• Ciencias sociales, psicología y política: La simulación participativa puede ayudar a comprender el comportamiento de personas a un nivel macro, como sociedades, y micro, como individuos.

• Ciencias exactas (computación y matemáticas, entre otras): La metodología permite simular el comportamiento práctico de redes informáticas o numéricas de manera dinámica. Se pueden también simular algoritmos distribuidos o problemas de programación dinámica.

• Economía y geografía: Leyes de oferta y demanda, simulación general de mercado, redes de distribución y análisis de procesos son algunos de los temas tratables con la simulación participativa.

• Medicina, ecología y biología: Se pueden simular el comportamiento de un virus, evolución y diagnóstico de cuadros clínicos, equilibrio ecológico, impacto ambiental, así como procesos genéticos y evolución.

79

6. Conclusiones

A continuación, realizaremos un sumario de las principales ideas generadas durante el desarrollo de este trabajo. A partir de ellas, podremos obtener reconocer con qué nivel, cuantitativo y cualitativo, fueron alcanzados los objetivos propuestos en la sección 1. Además, resumiremos las propuestas para posibles mejoras de la plataforma, así las aplicaciones que puedan ser construidas a partir del framework desarrollado.

La computación tiene el potencial de ser utilizada en la sala de clases para apoyar el proceso de aprendizaje. Pese a ello, las herramientas computacionales que permiten a los alumnos interactuar, relacionarse mutuamente y alcanzar objetivos educacionales de manera más satisfactoria, han evolucionado lentamente. Puntualmente, hay una carencia en torno a aplicaciones móviles colaborativas que permitan dinámicamente crear, asignar y distribuir tareas y objetivos en grupos cambiantes, formados en tiempo real, así como para el desarrollo de nuevas prácticas académicas, como las simulaciones participativas.

Existe un gran número de estudios que proponen alternativas y soluciones para la colaboración en la sala de clases, pero es imperante el llegar a un acuerdo respecto al alcance de las aplicaciones colaborativas educacionales y, así, plantear una plataforma común que permita lograr los objetivos necesarios para satisfacer dichas actividades. El presente trabajo propone y lleva a cabo el desarrollo de una plataforma flexible, orientada a permitir el desarrollo de múltiples aplicaciones móviles colaborativas, enfocadas mayoritariamente a la sala de clases.

La manera natural de interactuar con los dispositivos móviles es mediante gestos con el lápiz. El tamaño limitado de la pantalla impone un desafío al diseño de interfaces para estos equipos. Generalmente, estos dos conceptos han sido ignorados en el desarrollo de aplicaciones para dispositivos móviles, ya que utilizan metáforas comúnmente usadas en software para computadores de escritorio, las que no son válidas o adecuadas para handhelds. La plataforma descrita en este trabajo propone el uso de gestos mediante el lápiz como principal medio de interacción con el usuario.

La plataforma desarrollada presenta un diseño inspirado en la estructura de las actividades colaborativas. Esta una metaescructura está compuesta de un listado de modos, un árbol de participantes separados en grupos, y un árbol jerárquico recursivo de contenidos, comúnmente organizados por temas. Los programadores de software para actividades colaborativas móviles pueden basarse en esta arquitectura, extendiendo las capacidades adicionales que sean necesarias. Para ello, basta sólo con implementar modos adicionales, o complementar nuevas modalidades con las existentes, incorporando nueva funcionalidad y comportamiento a las aplicaciones. Dentro de estos modos, simplemente se debe seleccionar qué gestos permitirán qué acciones, utilizando las alternativas incorporadas o desarrollando nuevas formas de interacción a partir del sistema básico de reconocimientos de gestos.

80

A partir de la plataforma, se ha desarrollado múltiples aplicaciones para las áreas de apoyo a reuniones, toma de decisiones, diseño colaborativo, evaluación grupal y simulaciones participativas. Ellas se han basado en los modos y el reconocimiento de gestos incorporados en la plataforma, además de introducir nuevas alternativas desarrolladas por los programadores de cada aplicación. Particularmente, la plataforma fue exitosamente empleada para generar una aplicación de soporte a una simulación participativa puntual relacionada con la enseñanza del impacto del prestigio en las relaciones comerciales.

6.1. Alcance de los objetivos

Tal como ha sido planteado, el objetivo principal de este trabajo es diseñar, implementar y utilizar una plataforma para permita desarrollar aplicaciones que soporten actividades colaborativas. Podemos desprender de sección Implementación así como en las múltiples aplicaciones presentadas en la sección 5, que dicho objetivo ha sido alcanzado: se han construido diversas herramientas relacionadas con la colaboración en variadas áreas a partir de la plataforma desarrollada.

En particular, tal como describe el punto 4.4, se ha llevado a cabo la creación de una aplicación configurable que permite la realización de simulaciones participativas. Con ella, el profesor puede diseñar múltiples escenarios de negociación para apoyar la enseñanza del concepto “prestigio e información en las relaciones comerciales”.

Este framework ha mostrado ser flexible y extensible, además de incorporar capacidades de comunicación de información, detección de enfrentamientos cara a cara, reconocimiento de gestos mediante el lápiz, y formación y administración de grupos, conservando un tamaño reducido y respetando las limitaciones tecnológicas presentes en los dispositivos móviles y los ambientes donde las actividades se llevarán a cabo. Gracias a estas razones, podemos reconocer que satisface el objetivo principal de este trabajo, concibiendo una plataforma capaz de permitir el desarrollo de aplicaciones móviles para actividades colaborativas.

6.2. Trabajo futuro

Habiendo alcanzado los objetivos propuestos para este trabajo, podemos reconocer las áreas donde la plataforma puede mejorar, así como un conjunto de aplicaciones que –basadas en el framework desarrollado- pudiesen convertirse en herramientas útiles para el apoyo de actividades colaborativas. Además, proponemos la creación de un software generador de simulaciones participativas genéricas, capaz de ser configurado por profesores, sin la necesidad de que un programador intervenga.

6.2.1. Nuevas características de la plataforma

La plataforma cuenta con una serie de funcionalidades que brinda a los desarrolladores la posibilidad de construir múltiples aplicaciones. Sin embargo, hay varios campos aún disponibles donde mejorar y complementar la biblioteca de funciones

81

disponibles. Estas nuevas capacidades comprenden gestos pasivos de reconocimiento, medios de negociación y transferencia de elementos, modos de organización de la información y pantallas autogeneradas de configuración y administración para las actividades.

Por ejemplo, tal como se aprecia en las aplicaciones llevadas a cabo, especialmente en el trabajo experimental de Karl Strasser, herramientas opcionales permiten a nuevos equipos generar soluciones creativas: paletas de colores y estilos brindan al usuario la capacidad de dibujar o escribir con líneas de distintas tonalidades y grosores; gestos innovadores permiten la creación de tablas y su reorganización.

Entonces, queda propuesta la incorporación de nuevas características de la plataforma, basadas en gestos, modos u otras herramientas, con el fin de complementar las posibilidades actualmente disponibles para el desarrollo de aplicaciones. Algunas de estas características son:

1. Gestos:

a. Administración de tablas del estilo de hojas de cálculo,

b. Reconocimiento de escritura,

c. Aprendizaje de gestos del usuario mediante redes neuronales u otros medios.

2. Otras herramientas y características:

a. Capacidad de anexar archivos ubicados en la pantalla, y la posibilidad de visualizarlos directamente cuando ellos sean imágenes o PDFs.

b. Paleta de colores para seleccionar el tono de los trazos,

c. Sistema de control de cambios, mediante deshacer y rehacer,

d. Sincronización de un repositorio común de archivos,

e. Compatibilidad con computadores de escritorio y pizarras electrónicas.

82

6.2.2. Aplicaciones propuestas

Resumiendo las secciones 5.1.2 y 5.2.2 de Posibles aplicaciones podemos reconocer una serie de posibles aplicaciones cuyo desarrollo puede impactar positivamente las actividades colaborativas apoyadas. Proponemos el diseño y desarrollo las siguientes soluciones:

1. Software para presentaciones mediante bocetos con feedback en línea.

2. Aplicaciones que permitan llevar a cabo simulaciones participativas en las áreas de:

a. Ciencias sociales, psicología y política;

b. Ciencias exactas; Economía y geografía; y

c. Medicina, ecología y biología.

6.2.3. Asistente para la creación de nuevas simulaciones participativas

La plataforma desarrollada permite que programadores construyan nuevas aplicaciones de simulación. Sin embargo, es necesario un importante conocimiento de lenguajes de programación y técnicas de desarrollo. La mayoría profesores no cuentan con conocimientos de programación, y son ellos las personas adecuadas a la hora de concebir una actividad colaborativa o simulación participativas para la sala de clases. Además, la necesidad de construir la aplicación de manera anticipada, compilándola y distribuyéndola en todos los dispositivos para la actividad, limita la creación de nuevas aplicaciones fuera de la sala de clases.

Es por estas razones que proponemos el desarrollo de un sistema que permita definir simulaciones participativas a partir de un conjunto de reglas. Ello brindaría a los profesores la capacidad de, no sólo modificar los parámetros de una actividad, sino los roles y normas de interacción involucrados en su desempeño, sin la necesidad de contar con un programador y todo el proceso de desarrollo de software. Así se superarían las barreras que limitan la creatividad a la hora de llevar a cabo nuevas actividades educacionales.

Sin embargo, dicho sistema plantea un sinnúmero de dificultades. Encontrar las interfaces adecuadas es el primero de los desafíos. Cómo permitir a los profesores definir las propiedades de una simulación es un complejo problema que probablemente sólo pueden resolver expertos en el diseño de interfaces y usabilidad. Podemos reconocer al menos seis etapas en este proceso, cada una de las cuales requiere métodos diferentes para su configuración. Ellas son:

1. Definir de los roles: El profesor debe identificar cuales serán los posibles roles que los alumnos pueden cumplir. Además, es necesario reconocer si es que

83

estos papeles serán definitivos, o si podrán intercambiarse durante la actividad. En algunos casos, los participantes podrían tener más de un rol al mismo tiempo.

2. Configurar de las variables de la actividad y de los roles: Durante la actividad, las condiciones del juego pueden cambiar de acuerdo a la acción de los participantes. Estas pueden ser globales como individuales. Por ejemplo, el calentamiento global podría ser un parámetro común a todos los participantes, mientras que el grosor de la capa de ozono puede ser particular a cada uno de los alumnos que representan distintas regiones del planeta.

3. Identificar los elementos o instrumentos de negociación: En ciertos casos, la simulación permitirá o estará basada en el intercambio de objetos. Tal como se observa en la aplicación para simulaciones desarrollada (ver sección 4.4) los participantes podrán transferirse mutuamente ítems representativos. Para ello, es necesario que el profesor construya de antemano dichos elementos, o seleccione gestos para que los mismos alumnos puedan crearlos. Además, deberá elegir cuándo ellos se podrán transferir, entre qué roles esto ocurre y cuales son los efectos que dicha transferencia tiene sobre las variables globales e individuales.

4. Definición de las reglas de interacción entre los participantes: El núcleo de las simulaciones participativas es la posibilidad de que dos o más alumnos interactúen entre sí. Cuando ellos lo hagan, sus roles jugarán un papel importante en qué tipo de efecto tendrá el encuentro sobre ellos: éste podría afectar sus variables internas, las de la actividad o incluso alterar sus roles. Por ejemplo, continuando con la línea de países y el clima, cuando dos participantes decidan establecer un acuerdo energético en torno a tecnologías ecológicas, sus gastos aumentarían y mientras que el calentamiento global disminuiría.

5. Configuración de la visibilidad de las variables: Es importante no sólo definir las variables globales e individuales de la actividad, sino que también determinar cuáles de ellas deben ser visibles por qué participantes o qué roles. Por ejemplo, en la actividad propuesta en [Colella 2000], el juego no tendría ningún sentido si es que los alumnos supiesen cuándo alguien está sano o enfermo.

6. Control de la actividad y las variables: Una vez que la simulación haya sido configurada, el profesor deberá ser capaz de iniciarla, inspeccionar su estado, modificar variables globales e individuales en tiempo real, así como dar fin a la simulación.

84

7. Referencias

- Alonzi, P., D.R. Lange and B.J. Simkins, 2000, “An Innovative Approach in Teaching Futures: A Participatory Futures Trading Simulation”, Financial Practice & Education, pp. 228-238.

- G Andrews, E Woodruff, KA MacKinnon, S Yoon, “Concept development for kindergarten children through a health simulation” - Journal of Computer Assisted Learning, 2003

- Ashwin 2006

- Bae Y, Lim J, Lee T, Mobile Learning System Using the ARCS Strategies, Proceedings of the Fifth IEEE International Conference on Advanced Learning Technologies (ICALT 2005).

- F. Baytelman, N. Baloian, M. Matsumoto, “Remote-lecture cooperative software system for the computer-integrated classroom”, IEEE Tencon 2004, Chiang Mai, Tailandia. Nov, 2004. P. 21-24.

- S. Brewster, “Overcoming the Lack of Screen Space on Mobile Computers”. Personal and Ubiquitous Computing, 2002, 6, pp. 188-205.

- AB Campbell , R Pargas, Laptops in the classroom, Proceedings of the 34th SIGCSE technical symposium on Computer science education, February 19-23, 2003, Reno, Navada, USA

- W. Citrin, P. Hamill, M. Gross and A. Warmack, “Support for Mobile Pen Based Applications”, In proceedings of MOBICOM 97, Budapest, Hungary, 1997, pp. 241-247.

- Colella, V., “Participatory Simulations: Building Collaborative Understanding through Immersive Dynamic Modeling” Journal of the Learning Sciences, 9, 4, 471–500. 2000.

- C. Cortez et al., “Teaching Science with Mobile Computer Supported”, Proceedings of the 2nd IEEE International Workshop on Wireless and Mobile Technologies in Education (WMTE'04)

- C. Cortez, M. Nussbaum, X. López, P. Rodríguez, R. Santelices, R. Rosasw & V. Marianov, “Teachers’ support with ad-hoc collaborative networks”… 2005

- G. Dai and H. Wang, “Physical Object Icons Buttons Gesture (PIBG): A new Interaction Paradigm with Pen”, Proceedings of CSCWD 2004, LNCS 3168, 2005, pp. 11-20.

- L. Denoue, P. Chiu and T. Fuse: Conference on Human Factors in Computing Systems. CHI '03 extended abstracts on Human factors in computing, Ft. Lauderdale, Florida, USA, 2003, 710-711.

- Francescato D., Porcelli R., Mebane M., Cuddetta M.,; Klobas J., Renzi P.: Evaluation of the efficacy of collaborative learning in face-to-face and computer-supported university contexts. Computers in human, 2006

- Funaoi, H.; Yamaguchi, E.; Inagaki, S.; Collaborative concept mapping software to reconstruct learning processes Computers in Education, 2002. Proceedings. International Conference on 3-6 Dec. 2002 Page(s):306 - 310 vol.1

- F. Guimbretiere, M. Stone, T. Winograd, ”Stick it on the Wall: A Metaphor for Interaction with Large Displays”, Proc. CHI’01 Workshop on Tools, Conceptual Frameworks, and Empirical Studies for Early Stages of Design, Seattle, Washington, USA, April, 2001.

- K. Hinckley, P. Baudisch, G. Ramos, And F. Guimbretiere, “Design and Analysis of Delimiters for Selection-Action Pen Gesture Phrases in Scriboli”, Proceeding of CHI 2005, ACM, 2005, pp. 451-460.

- U. Hoppe, K. Gaßner K, “Integrating Collaborative Concept Mapping Tools with Group Memory and Retrieval Functions”, Proceedings of the Computer Support for Collaborative Learning (CSCL) 2002 Conference, 2002, pp. 716-725.

- Jipping, M., Dieter, S., Krikke, J., and Sandro, S., “Using handheld computers in the classroom: laboratories and collaboration on handheld machines”, SIGCSE Technical Bulletin 33: 169–173. 2001.

- Kaner S, Lind L, Toldi C, Fisk S, Berger D, “Facilitator’s guide to participatory decision-making”, 2005.

85

- E. Klopfer, S. Yoon, L. Rivas, “Comparative analysis of Palm and wearable computers for Participatory Simulations”, Journal of Computer Assisted Learning, 2004.

- E. Klopfer, S. Yoon, J. Perry, “Using Palm Technology in Participatory Simulations of Complex Systems: A New Take on Ubiquitous and Accessible Mobile Computing”. Journal of Science Education and Technology 14:3, 285, 2005.

- V. Kostakos, E. O'Neill, “A Directional Stroke Recognition Technique for Mobile Interaction in a Pervasive Computing World”, People and Computers XVII, Proceedings of HCI 2003: Designing for Society, Bath, Sept 2003, pp.197-206, 2003.

- J. Landay and B. Myers, “Sketching interfaces: Toward more human interface design”, IEEE Computer, 2001 34(3), pp. 56-64.

- E. Lank and S. Phan, “Focus+Context sketching on a pocket PC”, Proceedings of CHI Extended Abstracts, 2004, pp. 1275-1278.

- D. Laurillard, chapter “E-Learning in Higher Education” from Changing Higher Education: The Development of Learning and Teaching”. London , Routledge 2006.

- T Larkin, D Budny. Learning Styles in the Classroom: Approaches to Enhance Student Motivation and Learning - - Information Technology Based Higher Education and Training, …, 2005

- L. Llanza, M. Matsumoto, N. Baloian, ”Human-Computer Interfaces for Electronic Board Supporting face-to-face Knowledge Exchange”, Graduate School of Global Information and Telecommunication Studies, Waseda University, Tokio, Japan. 2004.

- A. Long , J.. Landay , L. Rowe, “PDA and Gesture Uses in Practice: Insights for Designers of Pen-Based”, University of California at Berkeley, Berkeley, CA, 1998

- P. Lonsdale, C. Baber, and M. Sharples, “Engaging learners with everyday technology: A participatory simulation using mobile phones”, In Human Computer Interaction with Mobile Devices and Services (MobileHCI), Sept. 2004.

- P. Luff and C. Heath, “Mobility in Collaboration”. In Proceedings of Computer Supported Collaborative Work, CSCW’98. ACM Press, 1998, pp. 305-314.

- D. Marburger, “Comparing Student Performance Using Cooperative Learning”, International Review of Economics Education, volume 4, issue 1 (2005), pp. 46-57

- SJ Metcalf, RF Tinker, “Probeware and Handhelds in Elementary and Middle School Science”, Journal of Science Education and Technology, 2004.

- Thomas P. Moran, Patrick Chiu, and William van Melle. Pen-Based Interaction Techniques For Organizing Material on an Electronic Whiteboard. In UIST 1997, Symposium on User Interface Software and Technology, pages 45–54. ACM, 1997.

- MSDN: Microsoft Developer Network, .NET Compact Framework, http://msdn.microsoft.com/mobility/netcf/

- B. Myers, H. Stiel, and R. Gargiulo, “Collaboration using multiple PDAs connected to a PC”, Workshop on Shared Environments to Support Face-to-Face Collaboration at CSCW '2000, 2000, pp. 285-294.

- NanoXML, http://nanoxml.cyberelf.be/

- W. Penuel, J. Roschelle, L. Abrahamson, “Research on Classroom Networks for Whole-Class Activities”, IEEE International Workshop on Wireless and Mobile Technologies in Education (WMTE'05) pp. 222-229

- Roschelle, J., “Unlocking the learning value of wireless mobile devices”. Journal Computer Assisted Learning, 19(3) 260-272, 2003.

- H. Rystedt, B. Lindström, “Introducing simulation technologies in nurse education: a nursing practice perspective, Journal of computer assisted learning”, 19,260-272, 2001.

- S. Singhal and M. Zyda, “Networked Virtual Environments: Design and Implementation”, Addison-Wesley, 1999.

86

- Soller, A. L., “Supporting social interaction in an intelligent collaborative learning system”, International Journal of Artificial Intelligence in Education, 12, 40-62. 2001

- Swan, K., Cook, D., Kratcoski, A., Lin, Y., Schenker, J. & van ‘t Hooft, M, “Ubiquitous computing: rethinking teaching, learning and technology integration”. In S. Tettegah & R. Hunter (Eds.) Education and technology: Issues and applications, policy, and administration (pp. 231-252). New York: Elsevier. 2006

- Astrid Tomsic Dan Suthers. Effects of a Discussion Tool on Collaborative Learning and Social Network Structure within an Organization. Proceedings of the 38th Hawai`i International Conference on the System Sciences (HICSS-38), January 3-6, 2005,Waikoloa, Hawai`i (CD-ROM), Institute of Electrical and Electronics Engineers, Inc. (IEEE)

- Truscott, M. H., H. Rustogi, and C. B. Young, “Enhancing the macroeconomics course: An experimental learning approach”, Journal of Economic Education31 (Winter):60–65. 2000.

- P Vahey, V Crawford, “Palm Education Pioneers Program: Final Evaluation Report”, SRI Int’l, 2002

- Wilensky, U., Stroup, W.M. (1999) Participatory simulations: Network-based design for systems learning in classrooms. In Proceedings of the Computer Supported Collaborative Learning Conference (CSCL’99) pp. 667-676. Lawrence Erlbaum Associates, Mahwah, NJ

- Zurita, G., Nussbaum, M., “Computer supported collaborative learning using wirelessly interconnected handheld computers”, Computers & Education, 42(3), 289-314. 2004.

- G. Zurita, N. Baloian, F. Baytelman, “A Face-to-Face System for Supporting Mobile Collaborative Design using Sketches and Pen-based Gestures”, 10th International Conference on CSCW, Nanjing, China. Mayo, 2006. P. 250-255

- G. Zurita, P. Antunes, L. Carriço, F. Baytelman, M. de Sá, N. Baloian, “Analyzing the Roles of PDA in Meeting Scenarios”, 12th International Workshop on Groupware CRIWG 2006, Valladolid, España. Septiembre, 2006.

- PEP, Palm Education Pioneer. http://palmgrants.sri.com/, SRI International, 2000.