OrientaTree. Aplicación móvil para la realización de actividades educativas geolocalizadas en el medio natural

Escuela de Ingeniería Informática TRABAJO FIN DE GRADO Grado en Ingeniería Informática (Mención en Ingeniería del Software) OrientaTree Aplicación móvil para la realización de actividades educativas geolocalizadas en el medio natural Autor: Gabriel Rodríguez González Tutores: Alejandra Martínez Monés Juan Alberto Muñoz Cristóbal Agradecimientos Muchas gracias a Alejandra y Juan por su ayuda y su dedicación a lo largo de todo este proyecto, a Quico, Nesi y Felipe por esta colaboración que ha resultado tan interesante, y a mi familia, amigos y a Raquel por su apoyo. 2 Resumen Las carreras de orientación son un tipo de actividad formativa en el medio natural que pueden beneficiarse del uso de aplicaciones móviles. En este documento se describe el proceso por el que se ha diseñado y desarrollado una aplicación móvil que permite programar actividades de orientación educativa y participar en ellas. El medio natural en el que tienen lugar estas actividades es el Campo Grande de Valladolid. Las características del proyecto, que requería realizar un diseño de interacción con objetivos muy abiertos, nos llevaron a optar por una metodología de diseño centrado en el usuario, en la que pudimos contar con la participación de miembros de la Facultad de Educación y Trabajo Social. A lo largo del documento se describen las técnicas propias de dicha metodología que han sido empleadas y cómo nos han ayudado a obtener un producto de mayor valor para los usuarios. 4 Abstract Orienteering is a type of activity that takes place on natural enviroments and might be complemented with mobile aplications to extend its possibilities. On this document we describe the process of designing and implementing a mobile application that allows users to schedule educational orienteering activities as well as to take part on them. The natural enviroment on which these activities take place is Campo Grande (Valladolid). The initial requirements of the interaction for this project were very open. That made us choose a user-centered design methodology that enabled us to count with the colaboration of some members from the Education and Social Work Faculty. Throughout this document we will describe the different techniques from that methodology that have been used, and how they have assisted us on getting a much more valuable product for users. 6 Índice general Índice de figuras 11 Índice de tablas 13 1. Introducción 15 1.1. Contexto ................................................... 15 1.1.1. Colaboración del GSIC/EMIC y la Facultad de Educación y Trabajo Social . . . . . . . . . . 15 1.1.2. AFMNyorientación......................................... 15 1.1.2.1. Orientación con fines educativos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 1.1.2.2. Las aplicaciones móviles en el contexto de la orientación y la orientación con fines educativos ......................................... 16 1.2. Motivación .................................................. 17 1.3. Objetivos ................................................... 17 1.4. Organizacióndeldocumento......................................... 18 2. Plan del proyecto 19 2.1. Metodología.................................................. 19 2.1.1. Diseño Centrado en el Usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.1.2. DesarrolloIncremental........................................ 20 2.2. Planificación ................................................. 21 2.2.1. Faseinicial .............................................. 21 2.2.2. Iteracionesdedesarrollo....................................... 21 2.2.2.1. Primera iteración (17/04/21 - 29/04/21) . . . . . . . . . . . . . . . . . . . . . . . . 22 2.2.2.2. Segunda iteración (29/04/21 - 12/05/21) . . . . . . . . . . . . . . . . . . . . . . . . 22 2.2.2.3. Tercera iteración (12/05/21 - 26/05/21) . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.2.2.4. Cuarta iteración (26/05/21 - 05/06/21) . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.2.3. Análisisderiesgos .......................................... 23 2.2.3.1. Identificación de riesgos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.2.3.2. Análisis y priorización de riesgos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.2.3.3. Planificaciónderiesgos .................................. 24 2.3. Seguimientodelproyecto........................................... 26 2.3.1. Monitorizaciónderiesgos ...................................... 27 2.3.2. Comparación respecto a la planificación inicial . . . . . . . . . . . . . . . . . . . . . . . . . . 27 2.4. Presupuesto.................................................. 28 3. Geoposicionamiento en Aplicaciones Móviles 29 3.1. Métodos para el geoposicionamiento en las aplicaciones móviles . . . . . . . . . . . . . . . . . . . . . 29 3.1.1. Geoposicionamiento a través de GPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.1.2. Geoposicionamiento con apoyo de otros dispositivos . . . . . . . . . . . . . . . . . . . . . . . 29 3.1.3. Método de geoposicionamiento empleado en esta aplicación . . . . . . . . . . . . . . . . . . . 30 3.2. Ayuda al usuario para la identificación de objetos físicos usados como balizas . . . . . . . . . . . . . 31 3.3. Resumendelcapítulo............................................. 31 7 ÍNDICE DE TABLAS 7.15.CP02.Iniciarsesión. ............................................. 89 7.16. CP02-1. Iniciar sesión (e-mail incorrecto). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 7.17. CP02-2. Iniciar sesión (contraseña incorrecta). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 7.18. CP02-3. Iniciar sesión (e-mail no verificado). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 7.19.CP03.Restablecercontraseña......................................... 90 7.20.CP04.Cerrarsesión.............................................. 90 7.21. CP05. Cerrar sesión en medio de una actividad. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 7.22.CP06.Eliminarcuenta. ........................................... 91 7.23.CP07.Programaractividad.......................................... 91 7.24. CP07-1. Programar actividad (fecha anterior a la actual). . . . . . . . . . . . . . . . . . . . . . . . . 91 7.25.CP08.Accederaunaplantilla. ....................................... 92 7.26. CP08-1. Acceder a una plantilla (contraseña incorrecta). . . . . . . . . . . . . . . . . . . . . . . . . . 92 7.27.CP09.Encontrarunaactividad........................................ 92 7.28. CP09-1. Encontrar una actividad (colisión)................................. 93 7.29. CP10. Inscribirse en una actividad. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 7.30. CP10-1. Inscribirse en una actividad (clave incorrecta). . . . . . . . . . . . . . . . . . . . . . . . . . . 93 7.31. CP11. Comprobar ubicación del usuario al inicio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 7.32. CP13. Detección de paso por una baliza (modo lineal). . . . . . . . . . . . . . . . . . . . . . . . . . . 94 7.33. CP13-1. Detección de paso por una baliza (modo lineal y la baliza no es la adecuada). . . . . . . . . 94 7.34. CP13. Detección de paso por cualquier baliza (modo score)........................ 95 7.35. CP15. Detección de paso por cualquier baliza (modo score)........................ 95 7.36. CP16. Paso por meta tras alcanzar todas las balizas. . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 7.37. CP16-1. Paso por meta sin haber alcanzado todas las balizas. . . . . . . . . . . . . . . . . . . . . . . 95 7.38. CP17. Corrección de pregunta tipo test (respuesta correcta). . . . . . . . . . . . . . . . . . . . . . . 96 7.39. CP18. Corrección de pregunta tipo test (respuesta equivocada). . . . . . . . . . . . . . . . . . . . . . 96 7.40. CP19. Corrección pregunta de respuesta corta (respuesta correcta). . . . . . . . . . . . . . . . . . . . 96 7.41. CP20. Corrección de pregunta de respuesta corta (respuesta incorrecta). . . . . . . . . . . . . . . . . 97 7.42. CP21. Abandono de una actividad. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 B.1.Actividadeducativaroja...........................................113 B.2.Actividadeducativanaranja.........................................114 14 Capítulo 1 Introducción 1.1. Contexto La práctica de Actividades Físicas en el Medio Natural (AFMN) está en auge en la actualidad. Dentro del ámbito educativo, este tipo de actividades juega cada vez un papel más destacado, y es más frecuente encontrarlas incluidas en la programación de las materias escolares [9]. En el contexto de las AFMN, las actividades de orientación poseen una posición privilegiada debido su accesibilidad, la facilidad para implementarlas, y a que no hace falta una formación especial para el profesorado [9]. Por otra parte, las actividades de orientación pueden verse apoyadas y enriquecidas en distintos aspectos mediante su integración con las TIC. Este proyecto, que se realiza bajo el contexto de trabajo de fin de grado en Ingeniería Informática, y que está ligado al grupo de investigación GSIC/EMIC (Grupo de Sistemas Inteligentes y Cooperativos / Educación, Medios, Informática y Cultura)1, ha consistido en el desarrollo de una aplicación para la organización y participación en actividades de orientación educativa. A lo largo de esta introducción se explicarán más detalladamente todos estos conceptos. A continuación se describe brevemente qué es el grupo GSIC/EMIC, en qué áreas desarrolla su actividad, su relación con este proyecto, y cómo colabora con la Facultad de Educación y Trabajo Social. 1.1.1. Colaboración del GSIC/EMIC y la Facultad de Educación y Trabajo Social El grupo GSIC/EMIC es un grupo transdisciplinar que está compuesto por profesores, investigadores y personal laboral de la Escuela Técnica Superior de Ingenieros de Telecomunicación, la Escuela de Ingeniería Informática y la Facultad de Educación y Trabajo Social de la Universidad de Valladolid. La principal línea de investigación del grupo GSIC/EMIC es la del aprendizaje apoyado por la tecnología. En este ámbito lidera y colabora en distintos proyectos de investigación, donde se involucran también profesionales de otras áreas. Por ejemplo, en lo relativo a este TFG, el grupo lleva colaborando varios años con el departamento de Didáctica de la Expresión Musical, Plástica y Corporal en el apoyo mediante TIC al diseño y puesta en marcha de actividades educativas relacionadas con la orientación. Este proyecto se realiza dentro del marco de esa colaboración. A continuación, se explica brevemente en qué consisten las actividades de orientación y cómo las TIC pueden asistir y enriquecer la realización de estas actividades. 1.1.2. AFMN y orientación Como se ha mencionado anteriormente, las Actividades Físicas en el Medio Natural (AFMN) están cada vez más presentes en la programación de materias escolares como la Educación Física. En este proyecto nos hemos centrado en las actividades de orientación. La orientación es un deporte en el que cada participante realiza un recorrido cronometrado, con ayuda de un mapa y una brújula [7]. Los recorridos constan de una salida, una llegada (o meta) y los controles (o balizas). Los controles son los lugares por los que los participantes deben pasar, y están representados en el mapa de cada participante. El mapa que se usa en orientación deportiva es específico de este deporte, e incluye información topográfica, curvas de nivel, vegetación y otros elementos relevantes, con una codificación bien conocida (Figura 1.1). Al comienzo de la carrera, la ubicación de las balizas es desconocida para los participantes, por lo que estos 1Sitio web del grupo GSIC/EMIC: http://gsic.uva.es 15 CAPÍTULO 1. INTRODUCCIÓN deben ser capaces de encontrarlas empleando el mapa y la brújula. La modalidad más conocida y practicada de este deporte son las carreras a pie, aunque existen otras modalidades de orientación oficiales como orientación en bicicleta de montaña, orientación de precisión y esquí orientación [7]. Figura 1.1: Mapa de orientación. Tradicionalmente, la forma en la que los participantes demostraban que habían pasado por las balizas era utilizando “pinzas perforadoras”. Cada participante llevaba consigo una tarjeta de papel en la que iba haciendo marcas con las pinzas según alcanzaba las balizas. Las pinzas de cada baliza marcaban la tarjeta con un patrón único, por lo que los organizadores podían comprobar si el participante había pasado por los distintos controles. Actualmente es más habitual emplear un sistema de control electrónico en el que cada participante lleva consigo un chip que registra su paso por las balizas (en las que también hay un chip). 1.1.2.1. Orientación con fines educativos En el ámbito educativo, en ocasiones se busca trascender la faceta puramente deportiva de la orientación tradicional, enriqueciendo la actividad con un componente de aprendizaje. Esto da lugar a lo que se conoce como orientación con fines educativos [9]. En las actividades de orientación educativa los participantes no se limitan a registrar su paso por las balizas una vez las han encontrado, sino que al llegar a éstas se les plantea una actividad de carácter educativo que pueda enriquecer su experiencia de aprendizaje. Estas actividades pueden ser muy variadas, por ejemplo, responder alguna pregunta relacionada con el entorno en el que se encuentra la baliza, completar un reto o leer cierta información. Para gestionar todo ese contenido educativo, las TIC podrían ser de gran utilidad, dando soporte y permitiendo enriquecer las actividades con ese componente educativo. De hecho, como se verá a continuación, ya existe una gran variedad de aplicaciones móviles que se utilizan para la realización de actividades de orientación. 1.1.2.2. Las aplicaciones móviles en el contexto de la orientación y la orientación con fines educativos Como se ha mencionado, actualmente existe una gran variedad de aplicaciones móviles que se emplean para la realización de actividades de orientación. Por una parte tenemos las aplicaciones de orientación deportiva. Dentro de este grupo, podemos clasificar a su vez las aplicaciones de la siguiente manera: Realización de carreras/recorridos. Mediante estas aplicaciones los participantes de una actividad pueden registrar su paso por las distintas balizas. Además, en ellas también se registran los tiempos obtenidos por participantes, con los que se calcula una clasificación en la carrera. Algunos ejemplos de este tipo de aplicaciones son IOrientering2y MOBO3. 2IOrientering: http://www.iorienteering.com/ 3MOBO: http://mobo.osport.ee/ 16 CAPÍTULO 1. INTRODUCCIÓN Edición de mapas. Estas aplicaciones ayudan a diseñar mapas de orientación. Algunas de ellas también permiten diseñar y configurar los recorridos. Dentro de este grupo encontramos aplicaciones como Open Orienteering Mapper4. Juegos de simulación. Estas aplicaciones se utilizan para practicar y entrenar. Simulan carreras de orientación, planteando a los usuarios diferentes retos gracias a los cuales, éstos pueden mejorar su técnica de interpretación de mapas. La aplicación de escritorio Virtual-O5es un ejemplo de este grupo. Análisis de recorrido. Mediante estas aplicaciones los participantes pueden analizar su recorrido realizado durante una carrera. Entre ellas está la aplicación O’Route Orienteering. Aprendizaje teórico. Estas aplicaciones ayudan a los usuarios a aprender el contenido teórico de las carreras de orientación. Es decir, con ellas se aprende a interpretar los símbolos propios de la orientación, los mapas y la terminología específica. Algunos ejemplos serían O-Sudoku y O-Symbol. Además del grupo de las aplicaciones destinadas a la orientación deportiva, están las aplicaciones “generalistas”, que sin haber sido concebidas específicamente para ser empleadas en actividades de orientación, se han utilizado para enriquecerlas. En este grupo se encuentran aplicaciones comunes de realidad aumentada o lectores de códigos QR [12]. Por último, están las aplicaciones de “búsqueda del tesoro”, en las que los participantes tienen que ser capaces de alcanzar objetos ocultos al llegar a unas coordenadas. Ejemplos de este tipo de aplicaciones serían Geocaching6 y Munzee7. Hasta donde sabemos, no hay aplicaciones móviles destinadas específicamente a la realización de actividades orientación deportiva educativa que combinen el uso de mapas de orientación con contenido educativo. Como veremos en la siguiente sección, esta es la principal motivación para realizar el proyecto. 1.2. Motivación Este proyecto surgió a partir de una vieja idea en la que habían estado trabajando dos profesores colaboradores del grupo GSIC/EMIC hace veinte años. Aquella idea consistía en crear en el Campo Grande de Valladolid un entorno en el que poder realizar actividades de orientación tradicionales, con la peculiaridad de que se usarían como balizas eran elementos del propio entorno. Concretamente, se había realizado la labor de posicionar en un mapa de orientación una serie de árboles del Campo Grande, junto a los cuales el Ayuntamiento había colocado carteles que mostraban cierta información sobre los mismos. Con el tiempo esos carteles se fueron deteriorando, y muchos de ellos desaparecieron. Sin embargo, los árboles siguen allí. Veinte años después, la intención consistía en retomar el proyecto, pero esta vez, aprovechando las posibilidades que ofrece la tecnología móvil actual para desarrollar una aplicación. En principio, la aplicación estaría ligada al contexto escolar y al aprendizaje formal, especialmente al ámbito de la Educación Física en Primaria. Sin embargo, no se descartaba la idea de hacer que la aplicación fuera extensible a otros contextos (aprendizaje informal, uso turístico, recreativo, etc) y a otros escenarios (no solo el Campo Grande de Valladolid). En definitiva, la idea era retomar aquel proyecto incorporando las TIC para enriquecer las actividades de orientación con un mayor componente educativo, sin causar un impacto en el medio al no tener que dejar objetos físicos en el entorno, y ofreciendo mayor variedad y versatilidad a la hora de organizar actividades. 1.3. Objetivos El principal objetivo de este proyecto es: Diseñar y desarrollar una aplicación móvil mediante la que los docentes puedan programar y supervisar actividades de orientación educativa en un espacio físico concreto, y los estudiantes participar en ellas. Por otra parte, cabe destacar que el proyecto planteaba retos importantes desde el punto de vista de la usabilidad de las herramientas, debido a que involucra diferentes tipos de usuario, retos tecnológicos complejos, y escenarios de uso novedosos, a lo que se añade el reto de la poca precisión en la geolocalización que ofrecen los teléfonos móviles. Esto dio lugar a dos objetivos secundarios más: 4Open Orienteering Mapper: http://www.openorienteering.org/ 5Virtual-O: https://virtualo.org/ 6Geocaching: https://www.geocaching.com/play 7Munzee: https://www.playmunzee.com/ 17 CAPÍTULO 1. INTRODUCCIÓN Identificar y aplicar técnicas propias del diseño centrado en el usuario, con el fin de mejorar el diseño de la aplicación. Estudiar posibles alternativas para hacer frente a los retos derivados de la falta de precisión de los dispositivos actuales de geolocalización. En este trabajo de fin de grado, se desarrollará el front-end y el backend de la aplicación. Como se verá más adelante, la aplicación se comunica con el sistema de back-end para obtener los datos de las actividades y el contenido educativo de las balizas. En este proyecto, todos esos datos serán ejemplos representativos de actividades, creados junto con los colaboradores de Educación del proyecto. Es decir, que para configurar los datos existentes o añadir contenido nuevo, habrá que interactuar directamente con el sistema de back-end, pues no es objetivo de este proyecto desarrollar una interfaz que permita a un usuario no avanzado configurar nuevos tipos de actividades (aunque sería muy interesante implementarlo en el futuro). Esto es así porque de acuerdo a lo tratado durante las reuniones con los usuarios, se prevé que el rango de variantes y diferentes posibilidades que sería de utilidad incluir resultaría muy amplio y complejo, por lo que requeriría un estudio en profundidad cuya realización no sería asumible tratar de completar en este proyecto. 1.4. Organización del documento Tras estas secciones de introducción, el resto del documento se estructura de la siguiente manera: Capítulo 2. En este capítulo tratamos sobre la metodología seguida a lo largo del proyecto. También se habla sobre la planificación, incluyendo un análisis de riesgos. Además, se documenta el seguimiento realizado durante el desarrollo del proyecto, y se hace una estimación del presupuesto a partir de los datos anteriores. Capítulo 3. En el capítulo 3 se habla sobre los métodos de geoposicionamiento que se suelen utilizar en las aplicaciones móviles. Se discuten sus ventajas e inconvenientes, y se justifica la elección del método escogido para la implementación de esta aplicación. Capítulo 4. En este capítulo se trata acerca la investigación sobre usuarios realizada al inicio del proyecto. Además, también se incluyen las secciones habituales de la fase de análisis de un proyecto software (análisis de requisitos, dominio y casos de uso). Capítulo 5. El capítulo 5 trata sobre las decisiones de diseño tomadas para el desarrollo del front-end del sistema. Veremos, que gran parte de esas decisiones se fundamentan en las pruebas de usabilidad realizadas con usuarios reales a lo largo del proyecto. También nos detendremos en el diseño del back-end de la aplicación, centrándonos especialmente en la estructura de la base de datos NoSQL escogida. Capítulo 6. En este capítulo se detallan los aspectos más importantes de la implementación de la aplicación, y se explican algunas de las técnicas más interesantes que han sido utilizadas (especialmente el mapa de las actividades). Capítulo 7. En este capítulo veremos las pruebas realizadas para comprobar el funcionamiento de la aplicación. Capítulo 8. Por último, en el capítulo 8 se verán las conclusiones obtenidas al final del proyecto, así como las posibles líneas de trabajo futuro. 18 Capítulo 2 Plan del proyecto Este capítulo comienza con la descripción de la metodología adoptada para la realización de este trabajo de fin de grado, así como las razones que nos han llevado a elegir dicha metodología. Posteriormente, en la segunda sección del capítulo se describe la planificación establecida al inicio del proyecto. Finalmente, en la última sección del capítulo veremos cómo se han realizado el seguimiento y la monitorización del proyecto. 2.1. Metodología Como se ha comentado en el capítulo anterior, el objetivo de este proyecto es desarrollar una aplicación móvil mediante la que organizar y participar en actividades de orientación educativa. Se trata de una aplicación novedosa y destinada a usuarios poco expertos. Por lo tanto, es especialmente importante cuidar mucho el diseño de la interacción. Por otra parte, los usuarios de esta aplicación serán docentes del ámbito de la Educación Física y estudiantes de primaria. Como también se ha comentado anteriormente, el entorno colaborador del grupo GSIC/EMIC cuenta con algunos representantes del primer tipo de usuarios de la aplicación, lo cual nos da la oportunidad de involucrar a dichos usuarios en el proceso de diseño. Por otra parte, el desarrollo de la aplicación se ajusta bien a una metodología de diseño incremental. Por todas estas razones, la metodología elegida para la realización de este proyecto ha sido una combinación de diseño centrado en el usuario con desarrollo incremental, tal y como se explica en el resto de esta sección. 2.1.1. Diseño Centrado en el Usuario La metodología de diseño centrado en el usuario (DCU) consiste en una colección de procesos que tienen como objetivo situar a los usuarios de la aplicación en el centro del diseño y del desarrollo de ésta [22]. Es decir, que el desarrollo del producto software se realiza poniendo especial atención en los requisitos de los usuarios, sus objetivos y su feedback. Además de esta prioridad por centrar el diseño en las necesidades del usuario, la metodología DCU también persigue involucrarlos en el proceso de diseño a través de una serie de técnicas, con el objetivo de obtener productos altamente usables para ellos [17]. En resumen, la metodología DCU consta de estos cuatro principios básicos [28]: Foco inicial en los usuarios y sus tareas. Diseño iterativo. Medidas empíricas del comportamiento de los usuarios. Además, ISO 13407 [18] añade la participación activa de los usuarios y el establecimiento de grupos de trabajo interdisciplinar. En cada fase de un proyecto que sigue la metodología DCU, es importante ser capaces de entender el contexto en el que se utilizará la aplicación, especificar correctamente los requisitos de usuario, diseñar una solución y evaluarla con respecto a dichos requisitos. Para entender mejor el contexto y los requisitos de usuario, se usan técnicas de investigación sobre usuarios (capítulo 4). Por su parte, la elaboración de prototipos de bajo coste puede ser de gran utilidad para diseñar soluciones y presentárselas a los usuarios, con el objetivo de obtener feedback desde fases tempranas. Por último, los test de usabilidad pueden servir para evaluar las soluciones que hemos diseñado. Como se verá a lo largo del documento, para la realización de este proyecto se han utilizado todas esas técnicas propias de la metodología DCU. 19 CAPÍTULO 2. PLAN DEL PROYECTO 2.1.2. Desarrollo Incremental Aunque el DCU se puede integrar con diferentes metodologías de desarrollo, se complementa especialmente bien con las metodologías de desarrollo ágil [22] [8]. Esto es debido a la naturaleza iterativa de DCU. Además, al utilizar ambas conjuntamente, se contribuye a reducir algunos de los riesgos del proyecto (sección 2.2.3), así como a maximizar la satisfacción del cliente con el producto final. Por estas razones, para la implementación del software de este proyecto se ha elegido la metodología de desarrollo incremental basado en iteraciones. Se trata de una metodología ágil en la que, a diferencia del modelo en cascada, donde no hay iteraciones y todo el sistema se desarrolla de una sola “pasada”, el proyecto se divide en incrementos. En cada uno de esos incrementos o iteraciones, se realiza un ciclo completo como el que se ve en la Figura 2.1. De este modo, se va obteniendo cada vez una nueva versión de la aplicación más avanzada, que añade funcionalidad sobre la versión anterior (Figura 2.2). Esa funcionalidad debe aportar algún beneficio concreto a los usuarios, quienes gracias a esta metodología, pueden Figura 2.1: Fases del desarrollo incremental. Imagen obtenida de [15] (cap. 4). proporcionar al desarrollador feedback desde las primeras etapas de desarrollo, a medida que se les vaya entregando nuevas versiones. Finalmente, cuando se hayan completado todas las iteraciones de este proceso, el proyecto estará terminado [15] (cap. 4). Figura 2.2: Construcción de un sistema a partir de incrementos. Imagen obtenida de [15] (cap. 4). 20 CAPÍTULO 2. PLAN DEL PROYECTO Como se ha mencionado anteriormente, esta metodología de desarrollo es especialmente útil en el caso de proyectos como éste, donde se complementa con la metodología DCU. Gracias a la utilización de ambas se hace posible comprender muy bien las necesidades de los usuarios, así como ir comprobando si los productos que desarrollamos las satisfacen adecuadamente. Además, en este proyecto se va a desarrollar una parte de un sistema, por lo que esta aproximación puede ser muy útil para comprender qué funcionalidades conviene priorizar en cuanto a su implementación. Del mismo modo, también puede ayudarnos a reducir el riesgo de implementar funcionalidades que quizá no sean tan importantes para el usuario (gold-plating) [15] (cap. 4), como veremos en la subsección dedicada a los riesgos (2.2.3). 2.2. Planificación Este proyecto consta de algunas particularidades que merece la pena destacar en cuanto a su planificación. Por una parte, siguiendo la metodología DCU, se han reservado las primeras semanas para la realización de una fase inicial en la que llevar a cabo la investigación sobre usuarios. La otra particularidad es relativa a la forma de adoptar la metodología de desarrollo incremental para la implementación del software. Generalmente, para los proyectos que siguen dicha metodología se recomienda que cada incremento suponga entre un 1% y un 5% del total de la funcionalidad del proyecto, y que, preferiblemente, dure menos de un mes [15] (cap. 4). Para este proyecto se establecieron iteraciones de dos semanas. Sin embargo, hubo que planear cada incremento de tal forma que cubriese mayor porcentaje de funcionalidad de lo que habitualmente se recomienda. Esto es así porque si nos hubiéramos ajustado al máximo recomendado (5 % de la funcionalidad), harían falta diez meses para terminar el trabajo. Por esta razón, el proyecto está organizado en cuatro iteraciones, cada una de las cuales debería incrementar en un 25 % la funcionalidad de la aplicación desarrollada. Se deja margen para algunas iteraciones más al final, de una o dos semanas, de tal forma que haya cierta holgura por si alguna tarea se extiende en duración más de lo previsto. En la siguiente subsección, se describe más detalladamente cada una de las iteraciones previstas. Finalmente, algunas de las aproximaciones al método de desarrollo incremental sugieren que lo ideal es que tras la primera iteración tengamos un sistema completo con toda la funcionalidad básica cubierta. Tras las iteraciones posteriores se obtiene como resultado un incremento con una interfaz de usuario cada vez más refinada y detallada [24]. Para este proyecto, no se ha elegido esta aproximación, ya que además de la incertidumbre sobre la interfaz de usuario, también había cierta incertidumbre inicial sobre la funcionalidad y el alcance de la aplicación. Por lo tanto, hubiera sido arriesgado tratar de cubrir toda la funcionalidad básica en una primera versión. Por último, la metodología de diseño centrado en el usuario también desaconseja esta práctica, ya que probablemente resultaría en usuarios descontentos y cambios drásticos que habría que realizar posteriormente. 2.2.1. Fase inicial Según lo mencionado al inicio de la sección, y siguiendo la metodología DCU, este proyecto contará con una fase inicial en la que se realizará la investigación de usuarios. Durante ese tiempo, se mantendrán reuniones con los usuarios, se elicitarán requisitos, se clarificará el contexto en el que la aplicación será utilizada y se estudiarán los distintos escenarios. Los resultados obtenidos tras esta primera fase pueden consultarse en el capítulo 4. 2.2.2. Iteraciones de desarrollo Como se ha señalado anteriormente, este proyecto ha sido planeado para constar de cuatro iteraciones. Cada una de esas iteraciones debe producir un incremento en la funcionalidad de la aplicación, y constará de las cuatro fases que pueden observarse en la Figura 2.1: Diseño del incremento Construcción del incremento Implementación del incremento Evaluación de los resultados Al final de cada una de las iteraciones hay una fase de “Evaluación de los resultados” que se materializa en una reunión con los usuarios en la que se se utilizarán técnicas propias de DCU, como test de usabilidad con prototipos de bajo coste y pruebas con las versiones incrementales. Por otra parte, al principio de cada iteración también hay una reunión de seguimiento con los tutores. En esta reunión se tratan los avances realizados en la iteración anterior, se considera el resultado de la evaluación con los usuarios y se revisa la planificación para el incremento 21 CAPÍTULO 2. PLAN DEL PROYECTO actual. En la Figura 2.3 puede observarse la planificación prevista para las cuatro iteraciones del proyecto. Por último, cabe destacar que las tres últimas iteraciones incluyen una tarea que se desarrolla en paralelo con el resto de tareas durante toda la iteración. Esta tarea consiste en revisar, corregir y refinar la versión del incremento anterior, incorporando el feedback y las conclusiones obtenidas tras la evaluación con los usuarios. Figura 2.3: Diagrama de Gantt de las cuatro iteraciones del proyecto. 2.2.2.1. Primera iteración (17/04/21 - 29/04/21) El propósito de la primera iteración es obtener un prototipo de bajo coste interactivo que cubra las funcionalidades principales de la aplicación y que permita hacer una prueba de usabilidad con los usuarios. Respecto a la implementación, al término de esta iteración se prevee tener una primera versión de toda la parte de autenticación de usuarios y de programación de actividades por parte de los docentes (ver Figura 2.4). Figura 2.4: Diagrama de Gantt de la primera iteración. 2.2.2.2. Segunda iteración (29/04/21 - 12/05/21) La segunda iteración tiene como objetivo obtener como incremento una implementación que permita al usuario completar la forma más “básica” de actividad de orientación, es decir, sin contenido “educativo”. En esta iteración hay una tarea, relativa a la detección del paso por una baliza, que es especialmente delicada, por las dificultades técnicas. El diagrama de Gantt diseñado para esta iteración puede observarse en la Figura 2.5. Figura 2.5: Diagrama de Gantt de la segunda iteración. 22 CAPÍTULO 2. PLAN DEL PROYECTO 2.2.2.3. Tercera iteración (12/05/21 - 26/05/21) La versión de la aplicación resultante de esta iteración debe permitir realizar actividades de orientación pero con el añadido del contenido educativo en las balizas. Con esta versión, los usuarios pueden completar las actividades propuestas al pasar por una baliza, y también pueden compartir los datos de su actividad con el docente (ver Figura 2.6). Figura 2.6: Diagrama de Gantt de la tercera iteración. 2.2.2.4. Cuarta iteración (26/05/21 - 05/06/21) El objetivo para la cuarta iteración es tener toda la funcionalidad de la aplicación implementada. Los principales añadidos que contendrá esta versión sobre su predecesora serán: permitir a los docentes consultar los datos y las respuestas de los participantes de una actividad completada, y permitir a los usuarios ver su perfil y sus settings. Las actividades previstas para esta iteración pueden consultarse en la Figura 2.7. Figura 2.7: Diagrama de Gantt de la cuarta iteración. 2.2.3. Análisis de riesgos Otra fase importante de la planificación de un proyecto de desarrollo de software es la realización de un análisis de riesgos. Un riesgo hace referencia a un “posible evento o condición que, en caso de llegar a producirse, tendrá un efecto positivo o negativo sobre los objetivos de un proyecto” [15] (cap. 7). Durante la planificación de un proyecto se deben tener en cuenta los riesgos a los que este está expuesto, siguiendo los pasos que se describen en las siguientes subsecciones. 2.2.3.1. Identificación de riesgos Este paso consiste en identificar los posibles riesgos que pueden aparecer durante el desarrollo de un proyecto. A la hora de identificar los riesgos, existen principalmente dos técnicas que pueden facilitarnos la tarea: las checklist y las sesiones de brainstorming [15] (cap. 7). Las checklist recogen la experiencia de proyectos pasados, e información sobre algunos riesgos recurrentes en los proyectos de desarrollo de software. Un ejemplo bien conocido de checklist de este tipo es la lista con los diez riesgos más comunes en los proyectos de desarrollo de software, elaborada por B.W. Boehm [4]. 23 CAPÍTULO 3. GEOPOSICIONAMIENTO EN APLICACIONES MÓVILES el escenario de la actividad. Además, pueden requerir cierto mantenimiento. Como mínimo, hay que recargar su batería en algún momento. NFC (Near Field Comunication). NFC es una tecnología de comunicación inalámbrica, de corto alcance y alta frecuencia que permite el intercambio de datos entre dispositivos [20]. A efectos de esta aplicación, este método tiene más o menos las mismas ventajas e inconvenientes que los beacons. Al igual que éstos, también sería necesario desplegar los dispositivos por el terreno. Para establecer conexión entre dispositivos mediante esta tecnología, hay que estar a una distancia de centímetros, por lo que la certeza de que el usuario ha encontrado la baliza sería máxima. También como los beacons, es probable que su uso sólo fuera útil combinado con el GPS. De otro modo, la aplicación perdería toda noción de dónde está el usuario durante la actividad salvo cuando pasa por una baliza. Código QR (Quick Response code). Un código QR es un módulo para almacenar información en una matriz de puntos o en un código de barras bidimensional [19]. Los dispositivos móviles pueden escanear estos códigos mediante un lector específico. Se puede generar un código para cada baliza, y dejarlo en algún lugar a la vista, de tal modo que cuando el usuario pase por allí, pueda escanearlo. Entonces la aplicación puede registrar el paso del usuario por la baliza, y desencadenar alguna acción si es necesario. Al igual que los dos métodos anteriormente comentados, sirve para proporcionar a la aplicación una gran certeza de que el usuario ha pasado por un lugar en concreto. Respecto a los dos métodos anteriormente referidos, éste tiene la ventaja de ser más barato y requerir menos mantenimiento. Reconocimiento de los elementos del entorno. Se pueden identificar elementos del entorno mediante el reconocimiento de imágenes o visión artificial. Esta técnica es una disciplina científica que incluye métodos para adquirir, procesar, analizar y comprender las imágenes del mundo real con el fin de producir información numérica o simbólica para que puedan ser tratados por un ordenador [13]. Este método, consistiría en que el usuario obtuviese una imagen de la baliza mediante la cámara de su dispositivo. La aplicación sería capaz de discernir si la foto contiene al elemento del entorno adecuado. La razón de que se haya decidido no incluir este método por el momento, es que la dificultad técnica es muy grande. Los elementos que habría que reconocer son muy variados, y muy posiblemente, cambiantes. A día de hoy, sería difícil encontrar a nuestra disposición una tecnología que permitiese reconocer un árbol (posiblemente rodeado de más árboles) a lo largo de las distintas estaciones del año y desde distintos ángulos, con un grado de certeza aceptable. Sin embargo, a medida que la tecnología avance, puede que éste se convierta en un método muy interesante para incluir en la aplicación en el futuro. A la hora de incorporar a la aplicación una o varias de estas tecnologías, a parte de las ventajas e inconvenientes mencionados anteriormente, habría que tener en cuenta también otros aspectos. Por ejemplo, es importante considerar la mayor susceptibilidad al bandalismo y al deterioro que presentan estos métodos. Por otra parte, también se debe tener en cuenta que pueden limitar las posibilidades de generalización de la aplicación a otros escenarios, puesto que allí donde se pretenda realizar una actividad, previamente habrá que preparar el terreno. Por último, todos ellos causan un impacto en el entorno. 3.1.3. Método de geoposicionamiento empleado en esta aplicación En conclusión, atendiendo a la premisa de ofrecer una solución que no necesitara un despliegue previo y que no tuviera un impacto en el entorno, se optó por el GPS. Aunque en un principio nos pareció que su precisión no era suficientemente buena, el resto de ventajas que ofrece pesaron más, y nos hicieron decantarnos por este método. Esto implica que al diseñar las actividades, habrá que tomar la precaución de no situar las balizas a una distancia tan pequeña entre sí como para que el GPS pueda arrojar resultados ambiguos. Por otra parte, de las reuniones mantenidas con los usuarios se deduce que la precisión ofrecida por el GPS es suficiente para satisfacer sus necesidades, al menos en el contexto de este trabajo de fin de grado. La razón es que los usuarios reportan utilizar otras aplicaciones de orientación que también emplean el GPS como método de geoposicionamiento y cuya precisión, en general, les parece aceptable, si bien es cierto que un escenario como el del Campo Grande presenta retos adicionales por la complejidad del entorno y la potencial proximidad y similitud de las balizas entre sí. Por último, cabe destacar que el margen de error característico del GPS puede llevar a la situación de que un usuario se aproxime a una baliza y la aplicación automáticamente considere que la ha encontrado, cuando en realidad, es posible que el usuario no haya identificado el elemento del entorno que tenía que encontrar pese a estar cerca de él. Este problema es abordado con mayor detalle en la siguiente sección. 30 CAPÍTULO 3. GEOPOSICIONAMIENTO EN APLICACIONES MÓVILES 3.2. Ayuda al usuario para la identificación de objetos físicos usados como balizas Como se ha comentado en la sección anterior, en esta aplicación el problema de la geoposición tiene dos facetas. Por una parte, está la certeza con la que la aplicación puede llegar a saber si un usuario ha encontrado o no una baliza. Por otro lado, está la facilidad con la que un usuario es capaz de reconocer una baliza concreta. Es decir, que aún cuando un usuario se aproxime lo suficiente a una baliza como para que la aplicación interprete que la ha encontrado, puede ocurrir que dicho usuario no esté consiguiendo reconocer qué elemento del entorno conforma la baliza. Dependiendo del entorno, puede haber muchos elementos en un radio de diez metros (el margen de error esperado del GPS). Al fin y al cabo, en la orientación clásica, los participantes saben lo que buscan y qué aspecto tiene. Pero esto no tiene por qué ser así en el caso de las balizas que utilizará la aplicación, que formarán parte del entorno. La primera las dos cuestiones anteriormente mencionadas podría llegar resolverse prácticamente en su totalidad utilizando los métodos de geoposicionamiento apoyados mediante dispositivos físicos que se han detallado en la sección previa. Sin embargo, mientras no se incorporen dichos métodos al sistema, se pueden aprovechar algunas funcionalidades de la aplicación para reducir la incertidumbre, si ese es el objetivo. Por ejemplo, mediante la aplicación se pueden plantear al usuario retos o preguntas estrechamente relacionados con el entorno de la baliza, de tal forma que el hecho de que éste sea capaz de responder correctamente, ya constituya por sí mismo una prueba más de que el usuario efectivamente a llegado al lugar que debía. Para la cuestión de la capacidad de reconocer una baliza próxima por parte de los participantes, la aplicación puede proporcionar al usuario pistas (preparadas por los organizadores de la actividad). Estas pistas pueden ser imágenes o descripciones. Además, el uso de un mapa de orientación deportiva, donde se representa la baliza con precisión, ayuda también al usuario a identificar con certeza el elemento del entorno que corresponde a la baliza. En conclusión, las personas que organicen las actividades y configuren los recorridos, así como el “contenido educativo” de las balizas, podrán “jugar” con estos dos ajustes para conseguir una actividad con las características que deseen. 3.3. Resumen del capítulo En este capítulo se han analizado las distintas formas que existen de geoposicionar objetos y usuarios en el contexto de las aplicaciones móviles, así como sus ventajas e inconvenientes en el caso particular de este proyecto. Finalmente, el método elegido ha sido el geoposicionamiento mediante GPS. Como hemos visto, este sistema podrá verse complementado mediante la utilización “pistas” y “retos” que ayuden a reducir la incertidumbre causada por el margen de error propio del GPS, en aquellos casos en los que los diseñadores de las actividades lo consideren oportuno. Por último, no se descarta llegar a implementar en el futuro alguno de los métodos de geoposicionamiento apoyado mediante dispositivos discutidos en este capítulo. Esto dependerá en gran medida de si finalmente se opta por generalizar la aplicación a otros escenarios distintos al Campo Grande, o si por el contrario, se elige mejorar sus características para “afinar” su funcionamiento en dicho escenario particular y permitir implementar en él actividades en las que sea necesario un grado de precisión máximo. 31 Capítulo 4 Análisis En este capítulo veremos la investigación sobre usuarios propia de la metodología DCU realizada al inicio del proyecto. Además, veremos cómo dicha investigación nos ayudó a comprender mejor el dominio del sistema, las necesidades de los usuarios, los requisitos y los casos de uso, los cuales quedan documentados también en este capítulo. 4.1. Investigación sobre Usuarios Tal y como vimos en el capítulo 1, uno de los objetivos de este proyecto es identificar y aplicar técnicas propias del diseño centrado en el usuario, con el fin de mejorar el diseño de la aplicación. Además, en el capítulo 2 se mencionó que una de las principales características de dicha metodología es que busca situar a los usuarios en el centro del diseño de la aplicación. La investigación sobre usuarios consiste en un conjunto de métodos y técnicas que tienen como propósito ayudar a conseguir precisamente eso, centrar el diseño en el usuario [16]. Gracias a la investigación sobre usuarios aspiramos a alcanzar un entendimiento profundo sobre las personas que van a utilizar nuestro sistema, lo cual aumenta las posibilidades de crear un producto que ofrezca una experiencia de uso agradable, facilidad de aprendizaje y buenos niveles de usabilidad. 4.1.1. Proceso de investigación con usuarios En el capítulo 2 vimos que al inicio del proyecto, antes de comenzar con las iteraciones propias de la metodología de desarrollo incremental, se reservaba una “fase inicial” para llevar a cabo tareas de investigación sobre usuarios. La investigación sobre usuarios es especialmente importante durante el análisis del proyecto, ya que conviene tener un conocimiento profundo sobre nuestros usuarios antes de comenzar con el diseño. A continuación veremos en mayor detalle los usuarios sobre los que hemos centrado la investigación, así como los métodos de recogida de datos empleados. 4.1.1.1. Usuarios objetivo de la investigación En este proyecto, desde un primer momento pueden distinguirse dos grupos de usuarios bien diferenciados. Por una parte está el grupo de los docentes, quienes utilizan la aplicación para organizar actividades y ver el comportamiento de los estudiantes durante las mismas. El segundo grupo está formado por los estudiantes. Por otra parte, en el capítulo 1 del documento hemos visto que el grupo GSIC/EMIC cuenta con algunos colaboradores de la Facultad de Educación y Trabajo Social. Esta colaboración nos ha brindado la oportunidad de mantener reuniones y entrevistas con usuarios reales representativos del primer grupo (docentes, especialmente del ámbito de la Educación Física). De esta forma la aplicación se ha diseñado poniendo como eje las necesidades del profesorado, que es el que va a diseñar y poner en marcha las actividades educativas. El profesorado también representará las necesidades del alumnado, pero como se discutirá más adelante, una limitación de este proyecto ha sido la ausencia de representantes del alumnado en el proceso de investigación y diseño iterativo. 4.1.1.2. Métodos de recogida de datos En este apartado veremos los métodos de recogida de datos empleados para la investigación sobre usuarios del proyecto. 32 CAPÍTULO 4. ANÁLISIS Figura 4.1: Clasificacion de métodos de investigación sobre usuarios Imagen obtenida de [25]. La Figura 4.1 proporciona una visión general de algunos de los métodos de recogida de datos más comunes, clasificados en dos ejes de acuerdo a su naturaleza actitudinal odel comportamiento, y a si son cuantitativos ocualitativos. El primer criterio hace referencia a si un método de recogida de datos se basa en “lo que los usuarios dicen” o en “lo que los usuarios hacen” [25]. Por su parte, el segundo criterio clasifica los distintos métodos atendiendo a si los datos que se recogen son generados a partir de la observación directa (cualitativos) o mediante observación indirecta (cuantitativos). Habitualmente, los métodos cuantitativos implican la utilización de encuestas u otras herramientas analíticas, y nos permiten hacernos una idea de cuánto de común es un problema o cuánto de importante. En cambio, los métodos cualitativos acostumbran a ser más útiles a la hora de entender las causas y las posibles soluciones [25] para un problema. La Tabla 4.1 muestra los métodos que han sido utilizados para la recogida de datos a lo largo de este proyecto. Fecha Método Tipo Fase 10/03/21 Reunión de kick-off actitudinal y cualitativo Análisis 19/03/21 Group interview actitudinal y cualitativo Análisis 24/03/21 Stakeholders meeting actitudinal y cualitativo Análisis 07/04/21 Focus group para concept testing actitudinal y cualitativo Análisis/Diseño 07/05/21 Test de usabilidad de comportamiento y cualitativo Diseño 18/06/21 Test de usabilidad de comportamiento y cualitativo Diseño Tabla 4.1: Métodos de recogida de datos empleados en el proyecto En la siguiente subsección analizaremos en qué consiste cada método y cómo se ha llevado a la práctica. 33 CAPÍTULO 4. ANÁLISIS 4.1.1.3. Desarrollo de la recogida de datos En este apartado analizaremos cómo se ha realizado la recogida de datos en el proyecto, utilizando los métodos que se enumeran en la Tabla 4.1. Como podrá observarse, en esta sección no se habla en detalle de los test de usabilidad. Esto es así porque ese método pertenece a la fase de Diseño, y por lo tanto, realizaremos un análisis más exhaustivo del mismo en el capítulo 5. A continuación se describen los métodos pertenecientes a la fase de análisis: Reunión de kick-off . Al inicio de un proyecto, la reunión de kick-off sirve para juntar a los participantes del mismo, formar equipo y discutir la visión inicial. En esta reunión también se tratan temas como el alcance del proyecto, los objetivos y el plan [30]. En nuestro caso, este encuentro tuvo lugar por videoconferencia el día 10 de marzo de 2021. En él participamos la mayoría de las personas involucradas en el proyecto: tres miembros del grupo GSIC/EMIC (dos de los cuales, tutores de este trabajo de fin de grado), dos colaboradores del grupo GSIC/EMIC pertenecientes a la Facultad de Educación, y el autor de este trabajo. Entrevista (group interview). Las entrevistas son un método de recogida de datos en el que el investigador realiza preguntas a los usuarios sobre algún tema de interés con el objetivo de obtener cierta información [23]. Para este trabajo, el día 19 de marzo de 2021 se realizó una entrevista grupal por videoconferencia en la que participamos conjuntamente los tres miembros de la Facultad de Educación colaboradores del proyecto, y el autor de este trabajo en el rol de entrevistador. En dicha entrevista el objetivo era comprender los requisitos de la aplicación, así como conocer la forma en que a los usuarios les gustaría interactuar con la tecnología para lograr sus objetivos. La entrevista se condujo de manera semi-estructurada [26], es decir, estuvo basada en un guion, pero se dejó libertad para tratar temas emergentes. Stakeholders meeting. Un stakeholders meeting es una reunión en la que participan todas las personas involucradas en un proyecto. Estas reuniones se pueden organizar con diferentes objetivos. En nuestro caso, la reunión tuvo lugar el día 24 de marzo de 2021 y en ella participamos todas las personas vinculadas a este proyecto. En cierto modo, la reunión fue una continuación del kick-off, ya que se trataron los mismos temas con la novedad de que los stakeholders de la Facultad de Educación presentaron por escrito un documento en el que describían todas las actividades que les gustaría realizar con la aplicación. De este modo, la reunión nos sirvió para concretar algunas ideas, descartar otras, y plantear otras para posibles proyectos futuros. Focus group para validación de conceptos (concept testing). Un focus group en un método de investigación de usuarios en el que los investigadores reunen a un pequeño grupo de personas (típicamente entre seis y nueve) para revisar y discutir cuestiones sobre un diseño en particular [3]. Estos encuentros son de gran utilidad en las primeras fases de un proyecto, y sirven para evaluar la idea, ver las diferentes aproximaciones que se pueden adoptar y cómo de valiosas son las distintas propuestas. En este proyecto se reunió por videoconferencia un focus group el día 4 de abril de 2021. En él se presentó un prototipo de baja fidelidad1a los tres representantes del grupo de usuarios conformado por los docentes. El objetivo era validar conceptos y comprobar que se habían comprendido bien sus necesidades. La Figura 4.2 muestra el prototipo empleado para esta sesión de recogida de datos. Se trata de un wireframe2creado con la herramienta Adobe XD3. Emplear un wireframe interactivo fue de gran utilidad teniendo en cuenta que la sesión tuvo que ser online debido a las circunstancias provocadas por la pandemia COVID-19. La Figura 4.3 muestra una imagen del desarrollo de la sesión. 4.1.2. Resultados de la investigación sobre usuarios En esta sección, se describen los resultados obtenidos tras la realización de las técnicas de investigación sobre usuarios anteriormente descritas. En el contexto de la metodología de DCU, es habitual plasmar esos resultados mediante la utilización de personas yescenarios. A continuación veremos en qué consisten dichas técnicas y qué resultados arrojan sobre la investigación de usuarios en este proyecto. 1Un prototipo de baja fidelidad es un prototipo de bajo coste y con poco realismo en el aspecto visual respecto a lo que será producto final. A diferencia de los prototipos de alta fidelidad, destinados las pruebas usabilidad, éstos se utilizan para comprobar que la funcionalidad que se va a desarrollar es correcta, sin prestar demasiada atención a los aspectos visuales o estéticos. 2Un wireframe es una representación digital de una página de un producto/aplicación con la que el usuario puede interactuar clickando sobre ella. 3Adobe XD: https://www.adobe.com/products/xd.html 34 CAPÍTULO 4. ANÁLISIS Figura 4.2: Prototipo de baja fidelidad creado con Adobe XD para la validación de conceptos con los usuarios. Figura 4.3: Transcurso de la sesión de Focus group para la validación de conceptos. 35 CAPÍTULO 4. ANÁLISIS 4.1.2.1. Personas El término persona hace referencia a un arquetipo de usuario cuyos objetivos y características lo hacen representativo de un conjunto de usuarios reales más amplio [10]. El procedimiento consiste en escribir descripciones de una o dos páginas sobre usuarios ficticios, incluyendo sus patrones de comportamiento, objetivos y habilidades, así como información contextual y del entorno en el que esa persona opera. Habitualmente, en estas descripciones también se incluyen una fotografía y algunos detalles ficticios más, que dotan de mayor realismo a las personas y ayudan a los diseñadores a empatizar mejor con los usuarios. Gracias a ello, se reduce el riesgo para los diseñadores de incurrir en lo que se conoce como diseño autorreferencial [10]. El diseño autorreferencial es lo que ocurre cuando los diseñadores conciben un producto como si ellos mismos fueran los usuarios finales, cuando en realidad, puede que sus objetivos, habilidades y necesidades sean muy distintos a los de dichos usuarios. La Figura 4.4 muestra de manera esquemática las distintas fases del proceso de diseño y cómo empatizar con el usuario tiene una importancia especial dentro de ese proceso, para lo cual, la utilización de personas es de gran ayuda. Figura 4.4: Design thinking process. Imagen obtenida de [10]. En este proyecto, la investigación sobre usuarios se ha centrado más en el grupo de usuarios formado por los profesores, ya que es al que se ha tenido acceso. Para representar a este grupo, se ha creado la persona de Alfredo Blanco, como puede observarse en la Figura 4.5. A su vez, el grupo de usuarios formado por los estudiantes de primaria se ha caracterizado mediante la persona de Úrsula Buendía, cuya descripción viene detallada en la Figura 4.6. Cuando en un proyecto se obtienen varias personas puede ser difícil y confuso tratar de diseñar teniendo a todas en mente a la vez. En estos casos se recomienda asignarles una prioridad. De este modo se define una persona primaria, que será la que más se tenga en cuenta a la hora de diseñar. El resto de personas serán secundarias. La recomendación es: “diseña para la primaria y acomoda para las secundarias” [10]. En este proyecto la persona de Alfredo Blanco es la primaria, mientras que Úrsula Buendía es la secundaria. Finalmente, como puede observarse en las Figuras 4.5 y 4.6, a la hora de crear ambas personas nos hemos centrado especialmente en entender los hábitos, las actitudes y las aptitudes que cada uno de los grupos presenta respecto a las TIC, así como sus objetivos y frustraciones. Esto es debido a que ambos grupos podrían tener diferencias significativas en ambos aspectos, y habrá que tenerlo en cuenta a la hora de diseñar. 36 CAPÍTULO 4. ANÁLISIS Figura 4.5: Persona 1. Alfredo Blanco, profesor de Educación Física. 37 CAPÍTULO 4. ANÁLISIS Figura 4.6: Persona 2. Úrsula Buendía, alumna de 5ºde primaria. 4.1.2.2. Escenarios Como hemos visto, en la metodología de DCU la utilización de personas es de gran ayuda a la hora de identificar cuáles son los usuarios/actores de nuestro sistema, así como sus características y necesidades. Es habitual complementar esta técnica con la utilización de escenarios. Un escenario es una situación ficticia que describe cómo una persona interactuaría con un producto o aplicación en un contexto determinado para lograr un objetivo [10]. Los escenarios ayudan a los diseñadores a entender cómo interactúan los usuarios con el sistema y cómo tiene que ser el flujo de esta interacción. Además, son de gran utilidad a la hora de recoger los requisitos del sistema. Los escenarios se escriben a alto nivel y vinculados a una persona. Describen un caso de uso que se considera probable que ocurra en una interacción real, donde la persona utiliza el sistema para lograr un objetivo. A continuación se describen los escenarios identificados para este proyecto, donde Alfredo y Úrsula son los actores protagonistas. 38 CAPÍTULO 4. ANÁLISIS Escenario 1 Actor Úrsula (alumna). Motivación Comenzar una actividad de orientación educativa. Intención Anotar su hora de salida y visualizar el mapa. Acción Accede al mapa de la actividad, anota su hora de salida y comienza con su participación. Resolución La aplicación comprueba que Úrsula está en la salida, entonces le permite visualizar el mapa, y empieza a hacer un seguimiento de su ubicación. Descripción Úrsula, junto a sus compañeros de clase, va a participar en una actividad de orientación educativa organizada por su profesor Alfredo. Antes de comenzar la actividad, todos se reúnen en el lugar de salida. Allí, Alfredo va dando la salida a los distintos participantes. Previamente, todos se han descargado el mapa de la actividad en la aplicación. Úrsula, cuando llega su turno, solicita a la aplicación comenzar. Entonces la aplicación comprueba que Úrsula se encuentra en el lugar de comienzo, anota la hora de salida y le muestra el mapa de la actividad. Úrsula comienza a buscar las balizas. Tabla 4.2: Escenario 1 Escenario 2 Actor Úrsula (alumna). Motivación Completar su paso por una baliza. Intención Identificar correctamente la baliza y completar el reto que la aplicación le plantee. Acción Solicita a la aplicación que muestre el reto y da respuesta al mismo. Resolución Úrsula responde a la pregunta planteada. La aplicación anota el resultado y proporciona un feedback. Úrsula continua con la actividad. Descripción Úrsula está en medio de una actividad de orientación educativa. Con ayuda del mapa que le muestra la aplicación, cree que se debe de estar acercando a una baliza. De repente, su móvil vibra y emite un sonido, indicando a Úrsula que acaba de alcanzar la segunda baliza de la actividad (el chopo). Entonces Úrsula abre en la aplicación el reto de la baliza. La aplicación le muestra una foto del chopo y una pregunta tipo test relacionada con la forma de las hojas de ese árbol. Gracias a la foto y a la ubicación de la baliza en el mapa de orientación que le muestra la aplicación, Úrsula es capaz de reconocer el árbol. Entonces responde a la pregunta. Acto seguido, la aplicación anota su respuesta y la felicita por haber acertado. Úrsula continua con la actividad. Tabla 4.3: Escenario 2 39 CAPÍTULO 4. ANÁLISIS 4.2.2.1. Requisitos de usabilidad Como veremos a continuación, la especificación de los requisitos de usabilidad se ha realizado utilizando medidas cualitativas heurísticas establecidas de acuerdo con los usuarios, tales como “poco tiempo” o “la mayor parte de las veces”. Estas medidas se concretarán a la hora de realizar las pruebas de usabilidad teniendo en cuenta de las características del prototipo prototipo o de la versión utilizada en cada una de ellas. RNF-05 Un usuario no experto debe ser capaz de programar con éxito una actividad por sí mismo/a. RNF-06 Un usuario que ya conoce la aplicación debe ser capaz de programar una actividad en poco tiempo. RNF-07 Un usuario no experto debe ser capaz de encontrar una actividad e inscribirse en ella exitosamente por sí mismo/a. RNF-08 Los usuarios deberán ser capaces de encontrar actividades e inscribirse en ellas en poco tiempo. RNF-9 Los participantes de una actividad deben ser capaces de reconocer los elementos del entorno que actúan como baliza la mayor parte de las veces. RNF-10 Los usuarios deben ser capaces de encontrar por sí mismos la pantalla de la aplicación que les permite dar respuesta a los retos de las balizas durante las actividades. 4.3. Casos de uso Los casos de uso representan el conjunto de interacciones que un usuario puede realizar con el sistema. Como hemos visto, esta aplicación permitirá tanto organizar actividades como participar en ellas. Sin embargo, los usuarios no se registran como “organizadores” o “participantes”, sino que hay un único tipo de usuario. Es decir, que en unas ocasiones un usuario asumirá el rol de “organizador” y en otras el de “participante”. Esto es así para facilitar una eventual generalización de la aplicación a otros contextos más allá de las aulas y el ámbito puramente escolar. Por motivos de claridad, los casos de uso aparecen divididos en tres Figuras (4.7, 4.8, 4.9). En la primera de ellas, aparecen los casos de uso que son independientes del rol que el usuario tenga en cada momento. La segunda muestra los casos de uso relativos a un usuario en el rol de “organizador”. Por último, en la Figura 4.9 aparecen los casos de uso pertenecientes a un usuario en el rol de “participante”. Figura 4.7: Casos de uso independientes del rol del usuario. 46 CAPÍTULO 4. ANÁLISIS Figura 4.8: Casos de uso pertenecientes a un usuario en el rol de “organizador”. Figura 4.9: Casos de uso pertenecientes a un usuario en el rol de “participante”. 4.4. Modelo del dominio En esta sección se describe el modelo del dominio de la aplicación. En él se representan las entidades conceptuales utilizadas y las relaciones existentes entre ellas. La Figura 4.10 es un diagrama de clases en el que se representa el modelo del dominio de este proyecto. 4.4.1. Relación de clases En este apartado se describen brevemente las clases representadas en el modelo del dominio de la Figura 4.10, con el objetivo de establecer una correspondencia entre dichas clases y las entidades del mundo “real” que 47 CAPÍTULO 4. ANÁLISIS Figura 4.10: Modelo del dominio. conceptualizan: PlantillaActividad. Los organizadores de las actividades no crean dichas actividades desde cero mediante la aplicación, sino que seleccionan un tipo de actividad ya existente de un “catálogo”. Lo que el usuario selecciona es una PlantillaActividad, a la que nos referimos en adelante como (plantilla). Ésta encapsula la información general de la actividad, es decir, datos como dónde se desarrolla, qué tipo de actividad es, sus normas o su descripción. Además, las plantillas están asociadas a un mapa. Por último, las plantillas son “reutilizables”, y se pueden programar muchas actividades a partir de cada una de ellas. Actividad. Las actividades son “instancias” de plantillas. Están asociadas a un usuario como organizador. Éste, al crearlas, selecciona una fecha de comienzo y una fecha de fin. También tiene la opción de decidir si la actividad se realizará según la modalidad de score o si estará permitido que los participantes soliciten asistencia con la ubicación. Como vemos, las actividades también tienen asociada una lista de participantes. Mapa. Los mapas contienen la información sobre el recorrido que los participantes tienen que realizar durante la actividad. A cada mapa le corresponde una imagen geoposicionada en la que aparece representado dicho recorrido. Los mapas también contienen la información sobre la localización de la salida y la meta de la actividad. Además, los mapas tienen asociado un conjunto de balizas. Baliza. La clase baliza del modelo del dominio contiene toda la información relativa a las balizas (puntos por los que tienen que pasar los participantes) de la actividad, es decir, datos como su ubicación y el número relativo de la baliza dentro del recorrido de la actividad. Las balizas están asociadas a un mapa, y pueden estar asociadas o no a un reto, dependiendo del tipo de la plantilla. Reto. Un reto está asociado a una baliza, y representa el contenido educativo de ésta. Las balizas de las actividades creadas a partir de una plantilla de tipo DEPORTIVA no tienen asociado ningún reto, ya que los participantes se limitan a pasar por ellas. En cambio, si la plantilla de la actividad es de tipo NARANJA, cada baliza tendrá asociado un reto de la subclase PreguntaRespuestaCorta. Si la plantilla es ROJA, entonces a cada baliza le corresponderá un reto de la subclase PreguntaTipoTest. Como puede observarse en la Figura 4.10, la relación de ambas subclases con la superclase Reto es de tipo mandatory ydisjoint. Esto quiere decir que cualquier instancia de un reto, tiene que pertenecer obligatoriamente a una y solo una de las subclases. El alcance de este proyecto no contemplaba la implementación de más subclases descendientes de Reto, sin embargo, esto sería de valor para los usuarios, ya que les gustaría poder realizar más tipos de actividades educativas. Por lo tanto, esto podría ser una futura mejora interesante para proyectos futuros. 48 CAPÍTULO 4. ANÁLISIS •PreguntaTipoTest. Esta clase representa el tipo de reto correspondiente a las balizas de las actividades programadas a partir de una plantilla ROJA. Contienen las posibles respuestas que se mostrarán al usuario, así como cuál es la respuesta correcta (para poder corregir la elección del usuario y/o proporcionarle un feedback). •PreguntaRespuestaCorta. Representa el tipo de reto correspondiente a las balizas de las actividades programadas a partir de una plantilla NARANJA. Contienen la información sobre cuál es la respuesta correcta. Usuario Esta clase representa la información que la aplicación guarda sobre los usuarios. Como vemos en la Figura 4.10, en la clase Usuario aparecen los datos de perfil. Además, vemos que cada usuario puede estar asociado a muchas actividades, a veces como organizador y otras como participante (en este caso el usuario se relaciona con la clase intermedia participación). Participación Una participación contiene la información relativa a la actuación de un usuario durante una actividad en la que participa. En ella se anotarán la hora de salida y la hora de finalización. Además, una participación estará asociada a un conjunto de ubicaciones y de pasos por balizas. PasoPorBaliza. El paso por una baliza representa una baliza alcanzada por un usuario durante una actividad. En él se anotará la hora a la que se produjo ese paso, así como la respuesta dada por el usuario al reto asociado la baliza (en caso de que hubiera algún reto). Ubicación Durante el transcurso de las actividades, la aplicación realiza un seguimiento de la ubicación de los participantes. De este modo, se forma un registro de ubicaciones gracias al cual se puede reconstruir el track del usuario durante la actividad. Una ubicación consta simplemente de un instante de tiempo y unas coordenadas. 4.5. Modelo de interacción En esta sección se describen los principales casos de uso de la aplicación mediante la utilización de diagramas de secuencia. Figura 4.11: Diagrama de secuencia del CU “Organizar una actividad”. 49 CAPÍTULO 4. ANÁLISIS Figura 4.12: Diagrama de secuencia del CU “Inscribirse en una actividad”. Figura 4.13: Diagrama de secuencia del CU “Responder al reto de una baliza”. 50 CAPÍTULO 4. ANÁLISIS Figura 4.14: Diagrama de secuencia del CU “Ver el track de un participante”. Figura 4.15: Diagrama de secuencia del CU “Ver clasificación de una actividad”. 51 CAPÍTULO 4. ANÁLISIS Figura 4.16: Diagrama de secuencia del CU “Ver respuestas de los participantes a los retos”. 52 Capítulo 5 Diseño Siguiendo la metodología descrita en el capítulo 2, el diseño ha seguido un modelo iterativo, con pruebas de usabilidad que involucran a participantes en los momentos críticos [28]. Además, se han tenido en cuenta principios generales de usabilidad, y se han considerado guías proporcionadas por las plataformas para facilitarla. En este capítulo veremos las decisiones de diseño tomadas basándonos en todo lo anterior, así como la arquitectura del sistema y el diseño de la base de datos. 5.1. Guías de diseño aplicadas En esta sección se describen las guías generales de diseño en las que nos hemos basado en este proyecto. Veremos que, por un lado, están basadas en las heurísticas de Nielsen [21], muy conocidas en el mundo del diseño de sistemas interactivos. Por otro lado, también se han seguido las guías de Material Design1. Finalmente, en esta sección veremos cómo se han combinado las guías de Material con las heurísticas de Nielsen, de tal forma que la aplicación de las primeras ha servido como medio para ajustarse a las segundas. 5.1.1. Descripción de las heurísticas de Nielsen Con el objetivo de alcanzar buenos niveles de usabilidad, a la hora de realizar el diseño nos hemos basado en la lista de Los 10 Principios Generales para el Diseño de la Interacción, de Jakob Nielsen [21], los cuales se describen a continuación: 1. Visibilidad del estado del sistema. El sistema debe comunicar a los usuarios su estado actual. Esto les permite conocer el resultado y las consecuencias de sus acciones, de tal modo que la interacción resulta predecible. 2. Elementos del sistema relacionados con elementos del mundo real. El diseño debe hablar “el lenguaje del usuario”, y no una jerga interna. Se recomienda seguir convenciones y hacer que la información aparezca en un orden lógico y natural. 3. Los usuarios tienen el control y libertad sobre la interacción. Es especialmente importante que sea posible deshacer acciones realizadas por error sin que el usuario quede atascado en la interacción. 4. Consistencia y estándares. Se debe mantener la consistencia interna (dentro de un mismo producto o familia de productos) y externa (convenciones propias de la industria). Esto facilita el aprendizaje de los usuarios, ya que los elementos resultan familiares y la interacción predecible. 5. Prevención de errores. En aquellas situaciones propensas a errores, se recomienda anticiparse a ellos para evitar que ocurran. Esto puede agilizar notablemente la interacción. 6. Reconocer en lugar de recordar. Se debe reducir al mínimo la cantidad de información que el usuario tiene que recordar. Para ello se recomienda mantener los elementos de la interfaz y las acciones visibles siempre que se pueda. 1Material Design: https://material.io/ 53 CAPÍTULO 5. DISEÑO 7. Flexibilidad y eficiencia de uso. Se recomienda incluir “atajos” para las acciones habituales. Además, conviene permitir a los usuarios configurar o personalizar dichos “atajos”. 8. Estética y diseño minimalista. Las interfaces no deben incluir contenido irrelevante, ya que puede disminuir la visibilidad relativa de los elementos que sí son importantes. 9. Ayudar a los usuarios a reconocer los errores, entender su causa y recuperarse de ellos. Se deben mostrar mensajes de error claros y entendibles. Además se recomienda acompañarlos de alguna sugerencia sobre cómo solucionarlos. 10. Ayuda y documentación. Aunque la mejor situación es aquella en la que el usuario no necesita ninguna explicación adicional para completar sus tareas, se recomienda incluir documentación que permita entender cómo realizarlas en caso de que fuera necesario. 5.1.2. Material Design Material Design es un sistema de diseño creado por Google para ayudar a equipos a construir experiencias de usuario de alta calidad en Android, IOS, Flutter y web. Pone a nuestra disposición una serie de componentes2con los que construir nuestra interfaz de usuario. Además, también ofrece una serie guidelines con recomendaciones para que podamos sacar el máximo partido a esos componentes, y para que usemos los temas, los colores, la tipografía y otros elementos, de manera efectiva. Basar el diseño de una aplicación en Material Design puede aumentar significativamente las probabilidades de obtener un producto con buenos niveles de usabilidad, ya que facilita cumplir con los principios enumerados en la lista de Nielsen. En cierto modo, Material nos evita tener que “reinventar” todo cada vez para ajustarnos a las recomendaciones anteriores. A continuación se muestran algunas capturas de pantalla de de la aplicación en las que se puede observar cómo Material Design nos ha ayudado a la hora de seguir los principios de la lista de Nielsen. El primer ejemplo lo encontramos en la Figura 5.1, que muestra la pantalla que ve el usuario al abrir la aplicación. La interfaz de esa pantalla se ha construido empleando los siguientes componentes y guidelines de Material: 1 2 3 4 Figura 5.1: Ejemplo de utilización de componentes y guidelines de Material en el diseño de la aplicación. 1: App Bar 2: Empty State (icono hecho por Flat Icons y obtenido de www.flaticon.com) 3: Floating Action Button 4: Navigation Drawer. 2Un componente Material hace referencia a un bloque interactivo para la construcción de interfaces de usuario 54 CAPÍTULO 5. DISEÑO 1. App Bar. El App Bar tiene el color primario del tema de la aplicación (verde claro), como recomienda Material. Sobre él se indica en letras negras en qué pantalla nos encontramos. Las tres etiquetas en la parte inferior del App Bar son un Tab. Se recomienda usar este componente para alternar entre contenido similar (en este caso actividades clasificadas según su estado temporal). Por último, en la esquina superior izquierda del App Bar vemos un icono de menú. Como puede observarse, estamos aplicando el principio 4: consistencia y estándares. 2. Empty State. Los Empty States son útiles a la hora de comunicar que no hay elementos para mostrar en una pantalla (aplicación del principio 1: hacer visible el estado del sistema). En estos casos, Material recomienda utilizar una imagen con un tono neutro o humorístico, y un mensaje claro que explique al usuario lo que ocurre. El aspecto de ambos no debe ser “accionable”, sino que se debe apreciar que su finalidad es informativa (principio 3: prevención de errores). 3. Floating Action Button. Se recomienda usarlo para iniciar la acción principal de esa pantalla (en este caso, unirse a una nueva actividad). Para el relleno del botón se recomienda emplear el color secundario del tema elegido, es decir, verde oscuro. También se puede apreciar que sobre dicho botón, a diferencia de sobre otros elementos, el icono es blanco. Esto es así porque el color negro no alcanza los criterios de legibilidad sobre un tono tan oscuro. 4. Navigation Drawer. Al pulsar el icono de menú del App Bar aparece este componente. Material recomienda utilizarlo para acceder a partes de la aplicación que guarden poca relación entre sí. Tanto este componente como el anterior, constituyen otro ejemplo de aplicación del principio 4: consistencia y estándares. Como puede apreciarse en las capturas de la Figura 5.1, también se aplica el principio 8: estética y diseño minimalista, ya que todos los elementos que constituyen la interfaz son relevantes y aportan algún valor a la interacción del usuario. A continuación, en la Figura 5.2 tenemos otro ejemplo de aplicación de los principios de Nielsen mediante la utilización de componentes y guidelines de Material. En la imagen se muestra la secuencia de pasos necesarios para programar una nueva actividad: 1 2 3 4 1.1 1.2 1.3 Figura 5.2: Secuencia de acciones necesarias para programar una actividad. 1. En la primera pantalla podemos apreciar la utilización de los componentes Chips (1.1), Radio Buttons (1.2) y Switch (1.3). Vemos que los Chips vienen acompañados de iconos que ayuda a los usuarios a comprender las acciones que van a desencadenar (principio 2: elementos del sistema relacionados con elementos del mundo real). La utilización del Switch para representar la activación o desactivación de un servicio también constituye una implementación del principio 2, al ser una clara metáfora de los interruptores del “mundo real”. 2. En la segunda pantalla aparece el Date Picker de Material. Este componente está optimizado para que el usuario pueda elegir una fecha con el menor coste de interacción posible (principio 7: Flexibilidad y eficiencia en el uso). Además, también relaciona elementos del sistema con elementos del mundo real (principio 2), ya que utiliza la abstracción de un calendario, que es el objeto del mundo real con el que las personas elegimos fechas de manera natural. 55 CAPÍTULO 5. DISEÑO 12 Figura 5.6: Etiquetas confusas. 1: En una actividad completada, la etiqueta “Participantes” mostraba la lista de participantes 2: En una actividad en curso, la etiqueta mostraba información general sobre la actividad y la lista con los participantes para darles la salida. primera prueba de usabilidad, para planificar ésta nos hemos basado en las recomendaciones de David Travis [27], obteniendo la siguiente estructura: Objetivos. La prueba fue concebida con un enfoque fundamentalmente formativo, es decir, la intención era recopilar datos que nos ayudasen a mejorar el diseño de la aplicación antes de su lanzamiento [29] (cap 3). No obstante, también había un componente sumativo, por el cual tratamos de medir el grado en que ciertos parámetros habían sido alcanzados. En este caso, el enfoque sumativo iba dirigido a medir cómo de bien funcionaba el aspecto de la geoposición, y si satisfacía o no las necesidades y expectativas de los usuarios. En esta prueba se utilizaron métricas de rendimiento y de satisfacción [29] (cap 3). Entre las primeras están: •Distancia (metros). Distancia a la que la aplicación detecta el paso por una baliza. •Retardo (segundos). Diferencia temporal con la que la aplicación notifica a todos los miembros de un grupo de participantes que han alcanzado una baliza, el paso por dicha baliza (idealmente debería ser 0 si llegan a la vez). •Calibrado del mapa. Precisión con la que la imagen del mapa de la actividad ha sido georreferenciada. Por su parte las métricas de satisfacción tienen que ver con lo que los usuarios piensan y sienten sobre su experiencia. Hablaremos sobre dichas valoraciones más adelante, al analizar los resultados y las conclusiones. Finalmente, esta prueba también tenía como objetivo identificar aspectos emergentes del diseño de la aplicación. Tareas. Para esta prueba de usabilidad se asignaron distintas tareas a los participantes en función del rol que éstos desempeñasen en cada momento (organizador/participante). La prueba se estructuró en tres actividades, en cada una de las cuáles, un usuario hacía de organizador/a y el resto de participantes. Las tareas del usuario en el rol de organizador/a fueron las siguientes: •Programar una actividad para la fecha y hora establecidas. •Monitorizar el comportamiento de los participantes durante el transcurso de la actividad. •Visualizar las respuestas dadas por los participantes, así como el track seguido por éstos durante la actividad. 62 CAPÍTULO 5. DISEÑO Por su parte, las tareas asignadas a los usuarios en el rol de participante fueron: •Realizar la actividad buscando las balizas y dando respuesta a los retos planteados en ellas. •Utilizar de vez en cuando la funcionalidad que permite ver dónde uno se encuentra situado sobre el mapa, para probar qué tal calibrada está la imagen. •Visualizar sus respuestas y su track al terminar la actividad. Elección de participantes. Los participantes de esta prueba fueron los mismos que en la prueba de usabilidad anterior, es decir, los dos profesores y el estudiante de la Facultad de Educación que se encuentran ligados a este proyecto. Además, debido a la complejidad técnica y de gestión de esta prueba (ya que se desarrollaba en un parque de grandes dimensiones), mis tutores de este trabajo de fin de grado me asistieron en el rol de observadores, a la vez que también hacían de participantes. Elección de una metodología. Esta prueba se realizó al aire libre, en el Campo Grande de Valladolid, pues esa era la única forma de poder probar una aplicación de estas características que permite realizar actividades físicas en el medio natural. 5.2.2.3. Desarrollo de la prueba Durante la realización de esta prueba se completaron tres actividades de distinto tipo (deportiva, naranja y roja). En cada una de ellas, uno de los usuarios asumió el rol de organizador/a, y el resto hicieron de participantes. Mientras tanto, uno de los tutores de este trabajo hacía de observador del organizador y otro de observador de los participantes (además de ser participante también). Para facilitar la toma de datos por parte de los observadores, y para que todos pudiéramos compartir ideas, en lugar de completar cada participante la actividad por su lado (que sería lo normal), íbamos todos en grupo. En la Figura 5.7 se han recogido algunas fotos tomadas durante el transcurso de la prueba. Figura 5.7: Varias fotos tomadas el día de la segunda prueba de usabilidad, en el Campo Grande. 5.2.2.4. Resultados y conclusiones A partir de las observaciones realizadas durante la prueba, así como el feedback proporcionado por los usuarios, podemos concluir que, en general, los resultados de la prueba fueron positivos, y que los usuarios manifestaron estar satisfechos con la aplicación. A continuación se describen aquellos aspectos de la aplicación para los que la prueba arrojó unos mejores resultados: 63 CAPÍTULO 5. DISEÑO Geoposicionamiento. Uno de los objetivos de la prueba, era comprobar qué tal se comportaba la aplicación en cuanto a la precisión con la que es capaz de obtener la ubicación de los usuarios. Además, también había que comprobar si esa precisión era la adecuada de cara a la usabilidad, ya que tanto un exceso como un defecto en la misma podía ser problemático. Hay que tener en cuenta que en un entorno como el del Campo Grande, puede haber zonas por las que está prohibido caminar. A menudo, los árboles que representan una baliza están en medio de una de esas zonas. La aplicación no debería forzar al usuario a tener que acercarse tanto como para verse obligado a pisar una de esas zonas prohibidas. En ese sentido, la aplicación se comportó adecuadamente, ya que detectaba el paso por las balizas a una distancia conveniente (radio de 20 metros aproximadamente). Además, la ubicación se obtenía con una precisión similar para todos participantes, de tal forma que al llegar en grupo a una baliza, todos recibían la notificación dentro de un lapso de tiempo de unos 3 segundos. Los usuarios manifestaron estar muy satisfechos con el comportamiento de la aplicación en ese aspecto, por lo que no hubo que realizar más ajustes en cuanto a la precisión a la hora de geolocalizar. Facilidad a la hora de reconocer las balizas. En el capítulo 3 vimos que uno de los retos al comenzar el proyecto era hallar la forma de conseguir que los usuarios reconocieran el elemento del entorno que constituye una baliza cuando lo tuvieran delante. Por esa razón, en esta prueba también queríamos comprobar cuál era la tasa de éxito a la hora de reconocer las balizas por parte de los usuarios. En todos los casos, los participantes fueron capaces de reconocerlas gracias a las indicaciones del mapa de orientación y las fotografías que se muestran. Los usuarios se mostraron satisfechos con este aspecto de la aplicación, por lo que todo parece indicar que este método de asistencia al reconocimiento de las balizas es adecuado. Manipulación del mapa de la actividad. En las actividades de orientación tradicionales se utiliza un mapa de orientación impreso en papel. Los mapas en papel tienen muchas características deseables en cuanto a la facilidad y flexibilidad que ofrecen a la hora de ser manipulados. De igual modo, para esta aplicación necesitábamos que el mapa fuera una imagen que permitiera ser rotada, aumentada y alejada con la mayor facilidad posible. Además, tenía que ser una imagen georreferenciada, de tal modo que se pudiera representar la ubicación del usuario sobre ella. Para conseguir esto se utilizó la funcionalidad de overlay (capa superpuesta) ofrecida por el SDK de Google Maps para Android4(ver 6.5). Se observó que los usuarios manipulaban el mapa con facilidad, encontrando de forma natural la manera de hacer rotaciones y zoom. Visualización del track realizado por los participantes. Los los participantes de una actividad, al término de la misma, pueden ver sobre el mapa de orientación su trayectoria seguida (track). El organizador también puede ver esta información para cada participante. Esta funcionalidad se cubrió mostrando a los usuarios el mapa de la actividad y proporcionándoles un Slider mediante el que podían controlar el avance del track a lo largo del tiempo de la actividad (Figura 5.10). El track se mostraba como una línea curva que unía una serie de ubicaciones consecutivas conocidas. La funcionalidad gustó mucho a los usuarios, ya que según nos hicieron saber, ofrece amplias posibilidades en el ámbito educativo. También se mostraron satisfechos con la forma en que podían visualizarlo y manipularlo mediante la aplicación. Sin embargo, les gustaría poder verlo también representado en su totalidad como una imagen fija. Esta característica fue introducida más adelante (segunda imagen de la Figura 5.10). A partir de la prueba, también se obtuvieron varios aspectos en los que la aplicación podría mejorar. Algunos de ellos se han podido corregir en el marco de este trabajo de fin de grado. Sin embargo, otros quedan recogidos y clasificados para trabajo futuro. A la hora de decidir cuáles de estos aspectos se corregirían y cuáles quedarían para trabajo futuro, se le asignó a cada uno una prioridad considerando la relevancia (o el valor) de la implementación y el tiempo que supondría realizarla, siguiendo el criterio que se muestra en la Figura 5.8. De acuerdo a ese criterio, en las Tablas 5.3, 5.4, 5.5, 5.6 y 5.7 aparecen priorizadas todos las tareas que surgieron a partir de la prueba. 4Sitio web de Google Maps para desarrolladores: https://developers.google.com/maps/documentation 64 CAPÍTULO 5. DISEÑO + Tiempo implementación - - Relevancia (valor) + PRIORIDAD Media Alta Alta Alta Media BajaBaja Baja Media Figura 5.8: Criterio para asignar prioridad a las implementaciones. Problemas de usabilidad detectados Prioridad Cuando un participante alcanza una baliza, no se le indica con la suficiente claridad que a continuación tiene que resolver el reto asociado a la baliza (Figura 5.11). Alta El organizador podría ver más claramente quién ha terminado la actividad y quién no, si esta información estuviera respaldada por un código de colores (ejemplo: participante que ha llegado a la meta aparece en color verde). Media Las notificaciones de paso por baliza deberían interrumpir lo que el usuario esté haciendo para asegurarse de que éste se da cuenta del evento. Media El término “en curso” para designar a las actividades que tienen lugar en el momento presente puede ser confuso, ya que parece implicar que el usuario está participando activamente en la actividad, cuando esto no tiene por qué ser así (por ejemplo, podría estar esperando a que le den la salida). Baja El término “organizar” para designar la acción por la que el organizador fija una actividad para un día y una hora puede ser confuso, pues parece implicar que el organizador puede crearla y configurar dicha actividad. Quizá sería más apropiado el término “programar”, pero habría que estudiar que opción es mejor. Baja Al mostrar las balizas alcanzadas, éstas aparecen ordenadas de forma que la alcanzada más recientemente se muestra arriba, mientras que hay que hacer scroll para ver las que fueron alcanzadas anteriormente. En ocasiones resulta confuso. Baja Sería útil que el organizador pudiera ver información general sobre la actividad de un participante (especialmente las balizas alcanzadas) sin tener que clicar sobre él. Esto mejoraría notablemente el coste de interacción (Figuras 5.12 y 5.13). Media Sería conveniente proporcionar al organizador una pantalla desde la que pueda monitorizar datos generales sobre transcurso de la actividad. Ahora mismo, solo puede ver el mapa e información específica de los participantes si clica sobre ellos (Figura 5.9). Alta Tabla 5.3: Problemas de usabilidad detectados durante la segunda prueba de usabilidad. 65 CAPÍTULO 5. DISEÑO Bugs detectados durante la prueba Bug Prioridad Si un participante cierra por error la pantalla en la que se ve el mapa de la actividad, no puede volver a abrirla sin reiniciar la aplicación. Alta Si un usuario quiere cerrar su sesión durante una actividad y hacer log-in con otra cuenta (lo cual no debería ser muy común), la aplicación falla. Alta Tabla 5.4: Bugs detectados en la aplicación durante la realización de la prueba de usabilidad. Posibles puntos de mejora Prioridad Mejorar el calibrado de las imágenes de los mapas, pues el track aparece desplazado sobre ellas. Media Mejorar la calidad con la que se ven los mapas de las actividades. Actualmente hay cierta pérdida de definición respecto a la imagen original. Media Tabla 5.5: Posibles puntos en los que la aplicación podría mejorar a raíz de las observaciones de los usuarios durante la prueba de usabilidad. Modificaciones en la lógica de las actividades Prioridad La aplicación debería proporcionar a los participantes de una actividad la posibilidad de abandonar ésta, de tal forma que el organizador pueda saber al instante que esa persona ya no está participando. Alta Mientras un participante está en medio de una actividad, no debería poder abandonar las pantallas relativas a dicha actividad. Media Convendría permitir a los participantes realizar varios intentos a la hora de dar respuesta a un reto. El número de intentos permitidos podría fijarse en dos para los retos tipo test, y tres para los retos de respuesta corta. También se podría dejar al organizador configurar este parámetro. Media No se debería permitir al participante abandonar la pantalla del reto de una baliza hasta que responda al mismo. Media Tabla 5.6: Modificaciones en la lógica y las “reglas” de las actividades. 66 CAPÍTULO 5. DISEÑO Funcionalidad adicional Prioridad El feedback que se proporciona a los participantes (5.12) debería ser más visual, intuitivo y “motivador” (considerar que normalmente los participantes serán niños/as). Media Sería de gran utilidad que el organizador pudiera ver en tiempo real (sobre el mapa) dónde se encuentra cada participante durante la actividad. Media Para poder comparar los tracks de distintos participantes sería interesante permitir mostrar varios a la vez sobre un mismo mapa. Media Se debería permitir a los usuarios registrarse en la aplicación mediante su cuenta de educacyl. Media Sería conveniente que la aplicación abriese automáticamente la pantalla del reto de una baliza cuando detecta que un participante la ha alcanzado. Media Se debería permitir al organizador de la actividad enviar avisos a los participantes durante el transcurso de la misma. Especialmente útil sería que hubiera un mensaje específico para solicitar a todos los participantes que regresen al punto de encuentro. Media Tabla 5.7: Funcionalidad que sería interesante implementar en un futuro. Tras analizar los resultados y priorizar las tareas descritas en las tablas anteriores, se corrigieron todas aquellas cuestiones cuya prioridad era “Alta”, que eran las que entraban dentro de la planificación y recursos del proyecto. A continuación veremos en qué se materializaron esas correcciones, y las decisiones de diseño tomadas más importantes. En primer lugar, en la Figura 5.9 podemos observar por un lado cómo era la pantalla de monitorización de la actividad en la versión de la aplicación con la que se realizó la prueba, y a continuación, la modificación que se introdujo a partir de los resultados obtenidos tras la misma. Como podemos apreciar, se ha incluido una pantalla adicional, en la que el organizador puede ver el mapa de la actividad. Durante la prueba de usabilidad, también descubrimos que la aplicación facilitaría el trabajo de los usuarios si permitiera visualizar el track completo seguido por un participante en una sola imagen. En la versión de la aplicación utilizada durante la prueba, los usuarios sólo podían ver a progresión a lo largo del tiempo del recorrido seguido, pero no lo podían representar entero. En la Figura 5.10 vemos las modificaciones introducidas. 67 CAPÍTULO 5. DISEÑO Figura 5.9: Pantalla del organizador. La imagen superior muestra la pantalla de monitorización de la actividad que veía el organizador. En la imagen inferior vemos que, tras la prueba de usabilidad, se ha añadido una nueva pantalla (centro). 1 2 Figura 5.10: Problema con los tracks. 1: Versión de la aplicación empleada en la segunda prueba de usabilidad. 2: Versión posterior de la aplicación en la que el usuario puede ver el track completo. Otra característica que fue introducida tras la realización de la prueba, fue la de indicar a los participantes, 68 CAPÍTULO 5. DISEÑO mediante un componente Badge de Material, el número de balizas alcanzadas para las que aún no han respondido al reto (Figura 5.11). Esta modificación tenía el objetivo de ayudar a los participantes a saber cómo actuar una vez encontrada una baliza. 12 Figura 5.11: Confusión con el botón de las balizas. 1: Versión empleada en la prueba de usabilidad (al principio los usuarios no sabían dónde pulsar para responder al reto de una baliza). 2: Modificación introducida a raíz de la prueba. El Badge indica el número de balizas cuyo reto está pendiente de responder. Por otra parte, en la Figura 5.12 se ilustran varios puntos en los que la usabilidad de la aplicación también podría mejorar. En primer lugar, durante la prueba se detectó que para los organizadores sería útil ver más información sobre los participantes desde la pantalla “Participantes” (especialmente el número de balizas alcanzadas, respondidas, acertadas y falladas). En esa misma pantalla, también sería de utilidad representar a los participantes con distinto color dependiendo de si aún no han comenzado la actividad, si están participando ahora, o si ya han terminado, del mismo modo que se hace para representar si el reto de una baliza ha sido respondido y si la respuesta ha sido correcta o no (pantalla “Balizas alcanzadas”). La tercera pantalla de la Figura 5.12 muestra el reto de una baliza junto con el feedback que se proporciona al participante. Según pudimos conocer gracias a la prueba, ese feedback tiene un tono demasiado sobrio, y debería ser más efusivo y motivador para niños. Finalmente, para solucionar la cuestión de que el organizador pueda, de un solo vistazo, hacerse una mejor idea general de toda la actividad realizada por un participante, se ha pensado que se podría utilizar un dashboard inspirado en el que emplea Moodle5para representar la totalidad de las preguntas respondidas y falladas por un usuario (Figura 5.13), pero adaptándolo a una interfaz móvil. Sin embargo, esta modificación, al igual que gran parte de las recogidas en las tablas mostradas previamente en esta sección, quedaría pendiente para futuras mejoras de la aplicación, ya que su implementación demandaría mucho más tiempo del disponible en un TFG. 5Sitio web de Moodle: https://moodle.org/ 69 CAPÍTULO 5. DISEÑO 1 2 3 Figura 5.12: Problema de usabilidad. 1: Listado de participantes desde el que el organizador puede clickar y ver la actividad de cada uno. 2: Balizas alcanzadas por cada participante. 3: Reto en una baliza. Figura 5.13: Dashboard de Moodle. Este dashboard podría inspirar la funcionalidad de que un organizador tenga consciencia del recorrido de un participante de un solo vistazo. 5.3. Arquitectura del sistema Esta aplicación se ha diseñado siguiendo el paradigma cliente–servidor. Como vemos en la Figura 5.14, la aplicación cliente o front-end (aplicación Android) abarca las capas de Presentación yLógica, mientras que el back-end (Firebase) es el servidor, que se encarga de la recuperación y manipulación de los Datos. Siguiendo este esquema, la aplicación cliente gestiona la lógica de las actividades. Los datos que se generan durante dichas actividades se almacenan en el back-end de Firebase, de tal forma que se sincronizan y están actualizados para todos los usuarios. Del mismo modo, la aplicación cliente obtiene los datos de las actividades y el contenido de las balizas mediante consultas que realiza hacia el back-end. Por último, en el back-end también se realiza toda la gestión de usuarios y almacena su información. 70 CAPÍTULO 5. DISEÑO Presentación Lógica Datos Front-end Back-end Figura 5.14: Capas de la aplicación y distribución entre front-end yback-end. Figura 5.15: Sincronización de datos entre dispositivos mediante Firebase. Imagen obtenida de [31]. 5.4. Back-end Como se ha mencionado en la sección anterior, el back-end de este sistema se encarga de gestionar y almacenar los datos de la aplicación, y de servirlos a los clientes cuando éstos lo solicitan. Para su implementación se ha elegido Firebase. Firebase es una plataforma de Google para el desarrollo de aplicaciones. Ofrece herramientas para cubrir gran parte de los servicios de back-end que habitualmente las aplicaciones requieren, tales como autenticación de usuarios, base de datos o almacenamiento de archivos, entre otros. Todos estos servicios están en la nube, alojados en componentes de back-end que Google se encarga de gestionar y mantener. Las aplicaciones cliente que utilizan los servicios de Firebase se comunican directamente con esos componentes. Esto lo hacen simplemente mediante la invocación end-points. De este modo, los desarrolladores no tienen que preocuparse de programar el back-end, pues de eso ya se encarga Firebase. Así, es habitual incluir Firebase dentro de los productos categorizados como “back-end as a service”. Finalmente, a diferencia de Google Cloud, Firebase va destinado principalmente a desarrolladores de front-end, a quienes les facilita poder centrarse en crear la parte de cliente de la aplicación, en lugar de tener que preocuparse de desarrollar y configurar también el back-end. Dicha característica hizo que Firebase se adaptase muy bien a las necesidades de este proyecto. Además, como vimos al tratar sobre los requisitos no funcionales (4.2.2), partíamos de la premisa de que la información del back-end debía ser accesible como REST 5Sitio web de Firebase: https://firebase.google.com/ 71 CAPÍTULO 5. DISEÑO Figura 5.20: Detalle del paquete adapters. Figura 5.21: Detalle del paquete modelo. Se han omitido las operaciones getter ysetter de las clases, así como los constructores. 78 CAPÍTULO 5. DISEÑO Figura 5.22: Detalle del paquete ui. 5.5.2. Servicio en primer plano para controlar la lógica de las actividades Como se ha mencionado al inicio de la sección 5.3, la lógica de las actividades reside en la aplicación cliente. Mientras un usuario toma parte en una actividad, la aplicación tiene que iniciar una tarea mediante la cual solicite constantemente actualizaciones sobre la ubicación del dispositivo. También tiene que ir almacenando ese historial de ubicaciones en el back-end, de tal modo que luego sea posible reconstruir el track. Además, tiene que ser capaz de determinar cuál es la siguiente baliza que el usuario debe alcanzar, y debe realizar una consulta hacia el back-end tanto para obtener el contenido educativo de la baliza alcanzada, como para actualizar la respuesta dada por el usuario. Para este tipo de tareas, que se ejecutan sin necesidad de que el usuario interactúe directamente con ellas, Android ofrece un componente de aplicación llamado Service. En este caso, el componente elegido para realizar estas tareas es un foreground service (servicio en primer plano), que se caracteriza porque hace saber al usuario que se está ejecutando mediante una notificación que permanece fija en la barra de estado. En la Figura 5.23 podemos observar cuál es el ciclo de vida de un componente Servicio. Figura 5.23: Ciclo de vida de un componente Servicio. Imagen obtenida de [1]. En el caso de nuestra aplicación, cada vez que el usuario decide comenzar o retomar una actividad, se llama al 79 CAPÍTULO 5. DISEÑO método startService y el Servicio se pone en marcha. Mientras el servicio se ejecuta, el usuario puede navegar por las distintas pantallas de la aplicación, bloquear su dispositivo o minimizar la aplicación. El Servicio se detendrá a sí mismo si el usuario completa la actividad o si se le acaba el tiempo. También se detendrá si el usuario decide abandonar o si cierra la aplicación. En este último caso, aún podrá retomar la actividad. 80 Capítulo 6 Desarrollo En este capítulo se describen las herramientas utilizadas para el desarrollo de la aplicación y se explica cómo se han implementado algunas de las características más interesantes del proyecto. 6.1. Lenguajes de programación y entornos de desarrollo La aplicación Android se ha desarrollado utilizando el lenguaje Java. Ocasionalmente se ha utilizado también JavaScript para el desarrollo de Cloud Functions. Las reglas de seguridad de la base de datos se han escrito utilizando el lenguaje propio de Firebase, el cual está basado en CEL1. 6.1.1. Android Studio Para el desarrollo de la aplicación Android, se ha utilizado Android Studio2, que es el entorno de desarrollo integrado oficial para la plataforma Android. Algunas de las ventajas más importantes que ofrece son: Compilación flexible basada en Gradle. Integración con GitHub. Compatibilidad integrada con Google Cloud Platform3y Firebase. Emulador de dispositivos Android. 6.1.2. Visual Studio Code Visual Studio Code4ha sido el IDE utilizado durante el desarrollo de este proyecto para la creación del código ejecutado en el servidor (Cloud Functions). La razón de utilizar este IDE, es que viene por defecto con soporte para JavaScript y Node.js. 6.2. Glide Para la descarga de imágenes desde la aplicación Android, se ha utilizado Glide5. Glide es una librería que ofrece una API muy sencilla de usar, mediante la que se puede encontrar, decodificar y mostrar imágenes de manera eficiente. Está especialmente indicada para aquellas aplicaciones que permiten al usuario hacer scroll para ir descargando más imágenes. 1CEL (Common Expression Language): https://github.com/google/cel-spec 2Android Studio: https://developer.android.com/studio 3Google Cloud Platform: https://cloud.google.com/ 4Visual Studio Code: https://code.visualstudio.com/ 5Glide: https://bumptech.github.io/glide/ 81 CAPÍTULO 6. DESARROLLO 6.3. Control de versiones: GitHub Para realizar el control de versiones de la aplicación y para alojar el código fuente se ha utilizado GitHub6. La metodología de trabajo seguida es la conocida como Gitflow Workflow. Esta metodología consiste en la utilización de feature branches para ir añadiendo nuevas características junto con dos branches especiales: main (o master) y develop. La rama main contiene el histórico oficial de todas las releases de la aplicación, mientras que develop sirve como branch de integración de nuevas características [2]. Figura 6.1: Representación de la metodología Gitflow Workflow. Imagen obtenida de [2]. 6.4. Firebase Emulator Suite Firebase Emulator Suite es un conjunto de herramientas para desarrolladores que permiten hacer pruebas en local sobre la mayoría de servicios que ofrece Firebase, simulando el comportamiento de éstos. En este proyecto se ha utilizado el Emulator Suite local para probar las Cloud Functions. Gracias a ello, se puede simular una base de datos Cloud Firestore y probar el comportamiento de nuestras funciones ejecutadas sobre dicha base de datos, en lugar de sobre nuestra base de datos de producción. 6.5. Mapa de las actividades y Google Maps SDK A priori, uno de los puntos que podrían suponer mayor dificultad técnica en cuanto a su desarrollo era encontrar la forma adecuada de implementar la visualización y el manejo de los mapas de las actividades. Lo ideal, sería disponer de una imagen georreferenciada que los usuarios pudieran manipular fácilmente, y que permitiera representar puntos geográficos y formas sobre ella. Para resolver este problema se utilizó una característica que ofrece Google Maps SDK: ground overlay. Esta técnica consiste en superponer una imagen sobre un mapa, como muestran las Figuras 6.2 y 6.3. Una vez tenemos la imagen situada en el lugar adecuado, tan solo tenemos que ocultar el mapa que hay “por debajo”, de tal modo que de la sensación de que no existe y que sólo está la imagen. 6GitHub: https://github.com/ 82 CAPÍTULO 6. DESARROLLO Figura 6.2: Imagen de un mapa de orientación superpuesta sobre el Campo Grande de Valladolid. Mapa Imagen Mapa Imagen Figura 6.3: Una vez la imagen está situada en el lugar adecuado, ocultamos el mapa que hay “debajo”. Respecto a las balizas, en la Figura 6.4 vemos cómo aparecen representadas sobre el mapa. Cabe destacar que forman parte de la imagen superpuesta al mapa, por lo que las representaciones son completamente estáticas. Esto es así porque el usuario no tiene que manipularlas ni realizar ninguna operación con ellas. La aplicación tan solo debe conocer sus coordenadas, de tal modo que para cada nueva ubicación del usuario, podamos calcular la distancia a la siguiente baliza y detectar si ha sido alcanzada. 83 CAPÍTULO 6. DESARROLLO Figura 6.4: Detalle de la representación de balizas sobre el mapa. Finalmente, Google Maps SDK también permite dibujar formas sobre un mapa. Esta característica ha sido utilizada para representar el track de los usuarios durante las carreras. Concretamente, se han empleado las Polylines, que consisten en una serie de puntos unidos mediante lineas. De este modo, para dibujar el track tan solo hay que crear un Polyline con todos los puntos que se quieran mostrar, y estos aparecerán sobre el mapa unidos entre sí. Para representar la progresión del participante como una sucesión de puntos que los usuarios puedan controlar (ver Figura 5.10), basta con mapear cada ubicación que forma parte del Polyline con un punto de la barra Slider. 84 Capítulo 7 Pruebas En este capítulo veremos las pruebas que se han realizado para comprobar el correcto funcionamiento de la aplicación. El capítulo se ha dividido en tres secciones. En primer lugar están las pruebas de las reglas de seguridad de la base de datos, a continuación se muestran las pruebas de la aplicación como tal, y por último, las pruebas realizadas para comprobar el funcionamiento de las Cloud Functions. 7.1. Reglas de seguridad de la base de datos Para probar las reglas de seguridad de la base de datos, que determinan quién puede acceder a qué datos de la aplicación, se ha utilizado la técnica de particiones en clases de equivalencia. Dicha técnica nos ayuda a optimizar los casos de prueba. Para realizar este proceso se ha utilizado la herramienta que proporciona la consola de Firebase a tal efecto (Figura 7.1). Figura 7.1: Herramienta integrada de Firebase para probar las reglas de seguridad. Cabe destacar que, como se verá a continuación, los casos de prueba se han dividido en subsecciones atendiendo a las distintas categorías de acceso dentro de la base de datos que definimos en 5.4.1.3 (“A”, “B”, “C” y “D”). 7.1.1. Categoría “A” Dentro de la categoría “A” se encontraban las siguientes colecciones: Plantillas, Balizas y Mapas. Sobre los documentos de esta categoría solo se pueden hacer operaciones de lectura. 85 CAPÍTULO 7. PRUEBAS Lectura categoría “A” Condición Clases válidas Clases no válidas Usuario autenticado Usuario está autenticado (1) Usuario no autenticado (1.1) Usuario verificado Usuario está verificado (2) Usuario no verificado (2.1) Tabla 7.1: Clases de equivalencia para la categoría “A”. Lectura categoría “A” Caso Clases cubiertas Esperado Obtenido Verificado y autenticado (1) y (2) Autorizado Autorizado No autenticado (1.1) Denegado Denegado No verificado (2.1) Denegado Denegado Tabla 7.2: Casos de prueba para la categoría “A”. 7.1.2. Categoría “B” La categoría “B” la conforma la colección de las Actividades. Lectura/escritura categoría “B” Condición Clases válidas Clases no válidas Usuario autenticado Usuario está autenticado (1) Usuario no autenticado (1.1) Usuario verificado Usuario está verificado (2) Usuario no verificado (2.1) Tabla 7.3: Clases de equivalencia para la categoría “B”. Lectura/escritura categoría “B” Caso Clases cubiertas Esperado Obtenido Autenticado y verificado (1) y (2) Autorizado Autorizado No autenticado (1.1) Denegado Denegado No verificado (2.1) Denegado Denegado Tabla 7.4: Casos de prueba para la categoría “B”. 7.1.3. Categoría “C” En la categoría “C” de la base de datos está la colección Usuarios. Lectura/creación categoría “C” Condición Clases válidas Clases no válidas Usuario autenticado Usuario está autenticado (1) Usuario no autenticado (1.1) Tabla 7.5: Clases de equivalencia para operaciones de lectura/creación en la categoría “C”. 86 CAPÍTULO 7. PRUEBAS Lectura/creación categoría “C” Caso Clases cubiertas Esperado Obtenido Autenticado (1) Autorizado Autorizado No autenticado (1.1) Denegado Denegado Tabla 7.6: Casos de prueba para operaciones de lectura/creación en la categoría “C”. Borrado/Actualización categoría “C” Condición Clases válidas Clases no válidas Usuario autenticado Usuario está autenticado (1) Usuario no autenticado (1.1) Usuario verificado Usuario está verificado (2) Usuario no verificado (2.1) ID usuario == ID doc ID usuario == ID doc (3) ID usuario != ID doc (3.1) Tabla 7.7: Clases de equivalencia para operaciones de borrado/actualización en la categoría “C”. Borrado/actualización categoría “C” Caso Clases cubiertas Esperado Obtenido Autenticado, verificado e ID == ID doc (1), (2), (3) Autorizado Autorizado No autenticado (1.1) Denegado Denegado No verificado (2.1) Denegado Denegado ID usuario != ID doc (3.1) Denegado Denegado Tabla 7.8: Casos de prueba para operaciones de borrado/actualización de la categoría “C”. 7.1.4. Categoría “D” La categoría “D” comprende las siguientes colecciones: Participaciones, Ubicaciones, PasosPorBaliza. Lectura categoría “D” Condición Clases válidas Clases no válidas Usuario autenticado Usuario está autenticado (1) Usuario no autenticado (1.1) Usuario verificado Usuario está verificado (2) Usuario no verificado (2.1) Tabla 7.9: Clases de equivalencia para operaciones de lectura en la categoría “D”. Lectura categoría “D” Caso Clases cubiertas Esperado Obtenido Autenticado y verificado (1) y (2) Autorizado Autorizado No autenticado (1.1) Denegado Denegado No verificado (2.1) Denegado Denegado Tabla 7.10: Casos de prueba para operaciones de lectura en la categoría “D”. 87 CAPÍTULO 7. PRUEBAS 7.2.4. Participación en actividades CP11 Comprobar ubicación del usuario al inicio Descripción Cuando un participante se dispone a comenzar una actividad, la aplicación debe comprobar que se encuentra en un lugar cercano a la salida. Acción Estando físicamente ubicado dentro de un radio de 150m respecto a la posición de salida, desde la pantalla de actividad en curso, pulsar sobre el botón comenzar. Resultado esperado La aplicación reconoce que el usuario está en un lugar cercano a la posición de salida, por lo que actualiza en Cloud Firestore la hora de salida y el estado de la Participación. Resultado obtenido Casi siempre correcto. En ocasiones, el usuario está en la salida pero la aplicación no lo detecta bien. En esos casos se puede abrir una aplicación que rastree la ubicación, como Google Maps. Tras unos instantes, la precisión de las ubicaciones se va afinando. Tras hacer ésto se vuelve a intentar comenzar la actividad y ya funciona. Tabla 7.31: CP11. Comprobar ubicación del usuario al inicio. CP13 Detección de paso por baliza (modo lineal) Descripción Un usuario participante de una actividad se acerca a la baliza que tiene que alcanzar y la aplicación lo detecta. Acción Durante el transcurso de una actividad, aproximarse a la próxima baliza que haya que alcanzar. Resultado esperado La aplicación envía una notificación informando de que se ha alcanzado la baliza cuando el usuario se encuentra a 20m aproximadamente. En Cloud Firestore se genera un documento de PasoBaliza. Resultado obtenido La gran mayoría de veces es correcto. Cuando no lo es, basta con esperar unos pocos segundos al lado de la baliza. Tabla 7.32: CP13. Detección de paso por una baliza (modo lineal). CP13-1 Detección de paso por baliza (modo lineal y la baliza no es la adecuada) Descripción Un participante se acerca a una baliza, pero no es la que tiene que alcanzar. Acción Durante el transcurso de una actividad, aproximarse a una baliza que no sea la siguiente que hay que alcanzar. Resultado esperado La aplicación no realiza ninguna acción. Resultado obtenido Correcto. Tabla 7.33: CP13-1. Detección de paso por una baliza (modo lineal y la baliza no es la adecuada). 94 CAPÍTULO 7. PRUEBAS CP14 Detección de paso por cualquier baliza (modo score) Descripción Un participante se acerca a una baliza (aún no alcanzada) en una actividad de tipo score. Acción Durante el transcurso de una actividad, aproximarse a una baliza no alcanzada aún. Resultado esperado La aplicación lo detecta cuando el usuario se encuentra a unos 20m y envía una notificación informando. En Cloud Firestore se genera un documento de PasoBaliza. Resultado obtenido La gran mayoría de veces es correcto. Cuando no lo es, basta con esperar unos pocos segundos al lado de la baliza. Tabla 7.34: CP13. Detección de paso por cualquier baliza (modo score). CP15 Paso por baliza ya alcanzada Descripción Un participante se acerca a una baliza que ya había alcanzado en esa misma actividad (score o lineal). Acción Durante el transcurso de una actividad, aproximarse a una baliza que ya haya sido alcanzada. Resultado esperado La aplicación no realiza ninguna acción. Resultado obtenido Correcto. Tabla 7.35: CP15. Detección de paso por cualquier baliza (modo score). CP16 Paso por meta tras alcanzar todas las balizas Descripción Un participante se aproxima a la meta después de haber alcanzado todas las balizas de la actividad. Acción Durante el transcurso de una actividad, aproximarse a la meta una vez alcanzadas todas las balizas. Resultado esperado La aplicación informa de que se ha llegado a la meta, anota el instante de finalización y cambia el estado de la Participación. Resultado obtenido Correcto. Tabla 7.36: CP16. Paso por meta tras alcanzar todas las balizas. CP16-1 Paso por meta sin haber alcanzado todas las balizas Descripción Un participante se aproxima a la meta durante la actividad sin haber alcanzado aún notas las balizas. Acción Durante el transcurso de una actividad, aproximarse a la meta sin haber alcanzado aún todas las balizas. Resultado esperado La aplicación no realiza ninguna acción. Resultado obtenido Correcto. Tabla 7.37: CP16-1. Paso por meta sin haber alcanzado todas las balizas. 95 CAPÍTULO 7. PRUEBAS CP17 Corrección de pregunta tipo test (respuesta correcta) Descripción Un participante responde adecuadamente a una pregunta de tipo test. Acción Durante el transcurso de una actividad, el participante pulsa sobre la baliza cuyo reto va a responder, y responde de manera correcta. Resultado esperado La aplicación detecta que la respuesta es correcta e informa al usuario. Actualiza en Cloud Firestore el documento del PasoBaliza. No permite al usuario volver a responder. Resultado obtenido Correcto. Tabla 7.38: CP17. Corrección de pregunta tipo test (respuesta correcta). CP18 Correción pregunta tipo test (respuesta equivocada) Descripción Un participante responde a una pregunta de tipo test de manera incorrecta. Acción Durante el transcurso de una actividad, el participante pulsa sobre la baliza cuyo reto va a responder, y responde de manera incorrecta. Resultado esperado La aplicación detecta que la respuesta no es incorrecta. Informa al usuario y le muestra cuál es la respuesta correcta. Se actualiza el documento de PasoBaliza en Cloud Firestore. No permite volver a responder al usuario. Resultado obtenido Correcto. Tabla 7.39: CP18. Corrección de pregunta tipo test (respuesta equivocada). CP19 Corrección pregunta de respuesta corta (respuesta correcta) Descripción Un participante responde a una pregunta de respuesta corta de manera correcta. Acción Durante el transcurso de una actividad, el participante pulsa sobre la baliza cuyo reto va a responder, y responde de manera correcta. Resultado esperado La aplicación detecta que la respuesta es correcta e informa al usuario. Actualiza el documento de PasoBaliza en Cloud Firestore y no permite al usuario que vuelva a responder. Resultado obtenido Correcto. Tabla 7.40: CP19. Corrección pregunta de respuesta corta (respuesta correcta). 96 CAPÍTULO 7. PRUEBAS CP20 Corrección pregunta de respuesta corta (respuesta incorrecta) Descripción Un participante responde a una pregunta de respuesta corta de manera incorrecta. Acción Durante el transcurso de una actividad, el participante pulsa sobre la baliza cuyo reto va a responder, y responde de manera incorrecta. Resultado esperado La aplicación detecta que la respuesta es incorrecta e informa al usuario. Actualiza el documento de PasoBaliza en Cloud Firestore y no permite al usuario que vuelva a responder. Resultado obtenido Correcto. Tabla 7.41: CP20. Corrección de pregunta de respuesta corta (respuesta incorrecta). CP21 Abandono de una actividad Descripción Un usuario abandona una actividad en curso en la que estaba participando. Acción Durante el transcurso de una actividad, desde la pantalla de actividad en curso, abrir el menú de overflow, pulsar en abandonar actividad yconfirmar. Resultado esperado Se detiene el servicio en primer plano que realiza el seguimiento de la ubicación del usuario. Se informa al usuario de que a abandonado la actividad. Se actualiza en Cloud Firestore el documento de su Participación y se pone en modo “Terminada”. Resultado obtenido Correcto. Tabla 7.42: CP21. Abandono de una actividad. 7.3. Pruebas de Cloud Functions Finalmente, en esta sección mostramos las pruebas realizadas para comprobar el funcionamiento de las Cloud Functions que habría que utilizar al poner la aplicación en producción. Para llevar a cabo estas pruebas se ha utilizado el emulador local de Firebase. 7.3.1. Sincronización de datos duplicados En las Figuras 7.2, 7.3 y 7.4 vemos cómo las funciones se desencadenan automáticamente cuando creamos o eliminamos un documento Participación (un usuario se inscribe o se da de baja de una actividad). 97 CAPÍTULO 7. PRUEBAS Figura 7.2: Borrado de una Participacion en el emulador local de Cloud Firestore. Figura 7.3: Mensaje de ejecución de la Cloud Function de borrado en el CLI de Firebase. Figura 7.4: Mensaje de ejecución de la Cloud Function de añadir Participacion en el CLI de Firebase. 7.3.2. “Limpiar” la base de datos En las siguientes Figuras vemos cómo la función encargada de eliminar el documento con los datos de un usuario se desencadena automáticamente al eliminar a ese usuario del servicio de autenticación (Firebase Authentication). Figura 7.5: Eliminar usuario desde el emulador local de Firebase Authenticacion. Figura 7.6: Mensaje de ejecución de la Cloud Function de eliminar el documento Usuario en el CLI de Firebase. 98 Capítulo 8 Conclusiones y trabajo futuro 8.1. Conclusiones Durante el desarrollo de este trabajo de fin de grado se ha conseguido desarrollar una aplicación móvil que permite a los usuarios programar actividades de orientación educativa en el Campo Grande de Valladolid, así como participar en ellas y revisar los resultados. Recordando los objetivos iniciales, podemos decir que éstos han sido conseguidos, y para cada uno de ellos se han alcanzado los siguientes hitos: Diseñar y desarrollar una aplicación móvil mediante la que los docentes puedan programar y supervisar actividades de orientación educativa en un espacio físico concreto, y los estudiantes participar en ellas. •Se ha desarrollado una aplicación móvil que cumple con los requisitos estipulados al inicio del proyecto. •En colaboración con un alumno y varios profesores de la Facultad de Educación, se han diseñado actividades de orientación educativa que han quedado alojadas en un back-end de Firebase. Identificar y aplicar técnicas propias del diseño centrado en el usuario, con el fin de mejorar el diseño de la aplicación. •Se han aplicado distintos métodos de investigación sobre usuarios a lo largo del proyecto: entrevista, stakeholders meeting yfocus group, gracias a los cuáles nos hemos podido hacer una mejor idea de la forma en la que los usuarios utilizan la aplicación. •Se han realizado dos pruebas de usabilidad con usuarios, a partir de las cuáles se ha extraído conocimiento valioso para realizar mejoras en la aplicación. •Se han aplicado principios, heurísticas y guías de usabilidad en el desarrollo de la aplicación. Estudiar posibles alternativas para hacer frente a los retos derivados de la falta de precisión de los dispositivos actuales de geolocalización. •Se ha investigado sobre las distintas opciones disponibles a la hora de realizar una geolocalización precisa, considerando las ventajas e inconvenientes de cada método. •Se ha aplicado exitosamente una forma de geolocalizar a los participantes de las actividades en la aplicación. Como mayor contribución, creemos que hemos aportado una primera propuesta de aplicación basada en el estudio de las necesidades y objetivos de los usuarios. Se ha alcanzado un entendimiento con los usuarios que ha dado lugar a una herramienta operativa que puede seguir siendo mejorada y ampliada en trabajo futuro. Las limitaciones del trabajo son muchas, debido al límite de tiempo. Quizá la más importante viene por el hecho de que no hemos trabajado con los estudiantes a la hora de hacer el diseño centrado en el usuario. 8.2. Trabajo futuro A continuación se describen algunos de los aspectos en los que el sistema desarrollado podría incorporar nuevas funcionalidades o mejorar las ya existentes: 99 CAPÍTULO 8. CONCLUSIONES Y TRABAJO FUTURO Desarrollar aplicación que permita la creación y configuración de nuevos tipos de actividades (“plantillas”). Incorporar las mejoras y las correcciones de prioridad “Media” y “Baja” expuestas tras la segunda prueba de usabilidad (ver 5.2.2.4). Incluir la opción de realizar actividades en modo “sin conexión”. En este caso habría que deshabilitar ciertas funcionalidades, como las actualizaciones en tiempo real que recibe el organizador sobre la actividad de los participantes. 8.3. Valoración personal Desde el punto de vista del aprendizaje, este proyecto ha sido muy enriquecedor. Una de mis principales motivaciones a la hora de realizar este TFG era aprender sobre usabilidad. En ese sentido, este proyecto ha supuesto la oportunidad de diseñar desde cero la interacción de los usuarios con una aplicación. Gracias a ello, he podido poner en práctica principios conocidos de usabilidad, como las heurísticas de Nielsen. También he aprendido mucho sobre el diseño de interfaces de usuario, gracias a haber trabajado siguiendo las guías de Material Design. En el aspecto metodológico, el proyecto ha sido de gran utilidad para practicar técnicas de diseño centrado en el usuario. El hecho de haber realizado iteraciones con usuarios para hacer evolucionar el diseño ha sido un aprendizaje muy valioso. El TFG también me ha servido para profundizar en conceptos sobre Android, ya que, previamente, casi no tenía experiencia en el desarrollo de aplicaciones móviles. Por último, este proyecto me ha servido para aprender sobre análisis y diseño de bases de datos NoSQL, como Cloud Firestore. 100 Bibliografía [1] Android Platform. Services overview. Computer Software. Android. url:https://developer.android. com/guide/components/services#Types-of-services (visitado 07-07-2021). [2] Atlassian Team. Gitflow Workflow.url:https : / / www . atlassian . com / git / tutorials / comparing - workflows/gitflow-workflow (visitado 27-06-2021). [3] Nick Babich. Why Focus Groups Benefit the Web Design Process. 30 de jul. de 2020. url:https://xd. adobe . com / ideas / process / user - research / why - focus - groups - benefit - web - design - process/ (visitado 07-06-2021). [4] Barry Boehm. «Software risk management: principles and practices». En: IEEE software 8 (1 ene. de 1991), págs. 32-41. [5] Raluca Budiu. Interaction cost: Definition. 31 de ago. de 2013. url:https://www.nngroup.com/articles/ interaction-cost-definition/ (visitado 28-04-2021). [6] Carlos Cabello. 9 usos reales para comprender qué son los “beacons”. 7 de jul. de 2016. url:https://www. nobbot.com/redes/9-usos-reales-comprender-los-beacons/ (visitado 28-04-2021). [7] Juan Manuel Casado Mora. Deporte de Orientación. 1.aed. Club de Orientación Veleta. 2009. url:http: / / www . criptanavertical . com / ORIENTACION / I % 5C % 20CARRERA % 5C % 20ORIENTACION % 5C % 20SAN % 5C % 20GREGORIO/Manual%5C%20Orientacion.pdf. [8] Claire Drumond. Agile Project Management.url:https://www.atlassian.com/agile/project-management (visitado 25-05-2021). [9] Juan Carlos Escaravajal Rodríguez y Antonio Extremera. «Las Aplicaciones Tecnológicas en el Deporte de Orientación y en Educación Física». En: Habilidad Motriz: revista de ciencias de la actividad física y del deporte 53 (oct. de 2019), págs. 28-40. [10] Patrick Faller. Putting Personas to Work in UX Design: What Are They and Why They’re Important? 17 de dic. de 2019. url:https://xd.adobe.com/ideas/process/user-research/putting-personas-to-work- in-ux-design/ (visitado 30-05-2021). [11] Firebase Team. Cloud Firestore. Computer Software. Firebase. url:https://firebase.google.com/docs/ firestore (visitado 17-06-2021). [12] Vanesa Gallego Lema y col. «La orientación en el medio natural: aprendizaje ubicuo mediante el uso de tecnología». En: 2.23 (2017), págs. 755-770. [13] Ana González Marcos y col. Técnicas y Algoritmos Básicos de Visión Artificial. Universidad de La Rioja, 2006. [14] GPS.gov. El sistema de posicionamiento global.url:https://www.gps.gov/systems/gps/spanish.php (visitado 28-04-2021). [15] Bob Hughes y Mike Cotterell. Software Project Management. 5.aed. McGraw-Hill Education, 2009. [16] Ditte Hvas Mortensen. User Research: What It Is and Why You Should Do It? Ene. de 2021. url:https: //www.interaction-design.org/literature/article/user-research-what-it-is-and- why-you- should-do-it (visitado 07-06-2021). [17] Interaction Design Foundation. User Centered Design.url:https: // www .interaction - design.org / literature/topics/user-centered-design (visitado 20-05-2021). [18] ISO. Human-centered design processes for interactive systems. en. Standard ISO 13407:1999. Jun. de 1999. url:https://www.iso.org/standard/21197.html. 101 BIBLIOGRAFÍA [19] ISO/IEC. Information technology – Automatic identification and data capture techniques – QR Code 2005 bar code symbology specification. en. Standard ISO/IEC 18004:2006. 2006. url:https://www.iso.org/ standard/43655.html. [20] NFC Forum. NFC Technology.url:https://nfcforum.org/whatis- nfc/aboutthe- technology/ (visitado 28-04-2021). [21] Jakob Nielsen. 10 Usability Heuristics for User Interface Design.url:https : / / www . nngroup . com / articles/ten-usability-heuristics/ (visitado 05-06-2021). [22] Ekaterina Novoseltseva. User-Centered Design: An Introduction.url:https://usabilitygeek.com/usercentered-design-introduction/ (visitado 07-06-2021). [23] Kara Pernice. User Interviews: How, When and Why to Conduct Them. 7 de oct. de 2018. url:https: //www.nngroup.com/articles/user-interviews/ (visitado 07-06-2021). [24] Joe Ritmeyer. Incremental UX. 29 de sep. de 2015. url:https : / / uxdesign . cc / incremental - ux - 62aa1283b105 (visitado 22-04-2021). [25] Christian Rohrer. When to Use Which User-Experience Research Methods. 12 de oct. de 2014. url:https: //www.nngroup.com/articles/which-ux-research-methods/ (visitado 03-06-2021). [26] Debbie Stone y col. User Interface Design and Evaluation. Morgan Kaufmann, 2005. Cap. 2. [27] David Travis. The 1-page usability test plan. 2 de sep. de 2013. url:https://www.userfocus.co.uk/ articles/usability_test_plan_dashboard.html (visitado 07-06-2021). [28] David Travis. The Fable of the User Centered Designer. 2010. url:https://www.userfocus.co.uk/fable/ (visitado 30-05-2021). [29] Tom Tullis y Bill Albert. Measuring the User Experience. 2.aed. Morgan Kaufmann, 2013. [30] Usability.gov. Kick-Off meeting.url:https://www.usability.gov/how-to-and-tools/methods/kickoff-meeting.html (visitado 06-06-2021). [31] Visual Paradigm Team. Firebase. Computer Software. Visual Paradigm. url:https://online.visualparadigm.com/diagrams/templates/google-cloud-platform-diagram/firebase/# (visitado 03-07-2021). 102 Apéndice A Manual de usuario A continuación se explica el funcionamiento de la aplicación desde el punto de vista de los usuarios. Mediante capturas de pantalla, se mostrarán las principales características de la aplicación y el flujo normal de acciones que los usuarios deben tomar para completar las tareas principales. A.1. Inicio de sesión y registro En esta aplicación los usuarios se identifican mediante e-mail y contraseña. Para que un usuario pueda utilizar la aplicación, no basta con que se registre, sino que también tendrá que verificar su e-mail. Para ello, se le enviará un correo con un link desde el que puede verificar su dirección, como el que se muestra en la Figura A.2. Análogamente, también podrá recuperar su contraseña en caso de olvido mediante un mecanismo similar, pulsando en restablecer contraseña (Figura A.1). Figura A.1: Pantallas de login, registro y bienvenida. 103 APÉNDICE A. MANUAL DE USUARIO Figura A.13: Visualización de los detalles de Mi Participación. A.7. Acciones del organizador Veamos a continuación las principales acciones que puede realizar el organizador de una actividad mediante la aplicación. En primer lugar, en la Figura A.14 observamos las pantallas desde las que el organizador puede monitorizar en tiempo real las acciones que realizan los participantes durante una actividad. En la Figura A.15 vemos cómo el organizador puede observar la información sobre una actividad terminada. En el caso de la actividad de la imagen, se trataba de una actividad de tipo “deportiva”, por lo que se puede ver una clasificación de los participantes de acuerdo a sus tiempos de finalización. 110 APÉNDICE A. MANUAL DE USUARIO Figura A.14: Pantallas de monitorización de la actividad. Figura A.15: Información sobre una actividad terminada. 111 Apéndice B Plantillas de actividades En este apéndice se describen las plantillas de actividades creadas a partir de la colaboración con dos profesores y un alumno de la Facultad de Educación y Trabajo Social. B.1. Actividad de tipo educativa roja Las plantillas de tipo “educativa roja” muestran a los usuarios preguntas de tipo test a su paso por las balizas. Esta plantilla tiene seis balizas cuyo contenido se muestra en la Tabla B.1. Figura B.1: Mapa de la plantilla educativa roja. 112 APÉNDICE B. PLANTILLAS DE ACTIVIDADES Baliza Texto y pregunta Respuesta 1. Catalpa Árbol de hoja caduca de hasta 20 metro de altura y copa ancha. Corteza gris con toques rojizos que se resquebraja. Sus hojas son muy grandes, en forma de corazón. Sus flores son blancas, con motas encarnadas y bandas amarillas en su interior, grandes y con forma de trompeta. El fruto es muy característico: muy alargado, estrecho y cilíndrico, de color verde al principio y después marrón. ¿Cómo es el fruto de este árbol? Muy alargado, estrecho y cilíndrico 2. Chopo Árbol de hoja caduca, puede llegar a los 40 metros de altura. Este árbol crece en zonas húmedas y se caracteriza porque tiene las hojas con forma romboidal a casi triangular y borde aserrado de color verde, las ramas son muy flexibles y la corteza es lisa. Un uso muy habitual de este árbol es para hacer pasta de papel. ¿Cómo son las ramas del chopo? Flexibles 3. Fotinia Arbolito de hoja perenne de hasta 7 metros de altura con copa amplia. El tronco es corto, ramificado y con corteza lisa, rojiza o marrón; parda en la madurez. Hojas ovaladas, verde oscuras con el borde irregular y del tamaño de una cuarta. Flores blancas semejantes a las del endrino que desprenden un agradable aroma. Los frutos son rojos y carnosos. ¿Qué forma tienen las hojas de la Fotinia? Ovaladas 4. Olmo Árbol de hoja caediza; de hasta 40 metros de alto con copa redondeada o en cúpula, frondosa. El tronco es robusto y las hojas no son simétricas. Actualmente esta especie casi ha desaparecido en su forma arbórea a causa de la grafiosis, una enfermedad mortal producida por un hongo que es transportado por un diminuto escarabajo barrenador. ¿Actualmente existen muchos olmos? No, casi ha desaparecido por culpa de un hongo (grafiosis) 5. Tejo Árbol de hoja perenne; de hasta 20 metros pero muchas veces tiene porte arbustivo en los ejemplares de jardinería. Hojas planas y estrechas, de hasta 3 centímetros, dispuestas en dos filas horizontales opuestas, una a cada lado de la rama. Sólo los ejemplares femeninos producen fruto. Se trata de una semilla rodeada de una cubierta roja muy llamativa que se denomina arilo. Toda la planta es venenosísima a excepción de la parte carnosa roja del fruto (arilo). Del Tejo se ha extraído taxol, empleado en tratamientos de quimioterapia contra el cáncer. ¿Para qué enfermedad se utiliza un extracto de esta planta en su tratamiento? Cáncer 6. Abedul Árbol de hoja caduca de hasta 30 metros de alto y con el tronco recto y ramificado. La corteza es muy blanca y distintiva; se agrieta y desprende en bandas horizontales. Sus hojas son romboidales o triangulares, con el borde doblemente dentado. Llaman la atención las flores masculinas, que agrupadas en pequeños cilindros cuelgan a principios de primavera. ¿De qué color es la corteza del Abedul? Blanca Tabla B.1: Actividad educativa roja 113 APÉNDICE B. PLANTILLAS DE ACTIVIDADES B.2. Actividad de tipo educativa naranja Las plantillas de tipo “educativa naranja” muestran a los usuarios preguntas de respuesta corta a su paso por las balizas. Esta plantilla consta de cinco balizas: Baliza Texto y pregunta Respuesta 1. Fotógrafo Escultura a escala humana, obra del escultor vallisoletanos Eduardo Cuadro. Es un homenaje a Vicente Muñoz, quien fue fotógrafo oficial del Campo Grande de Valladolid durante más de medio siglo. ¿En qué año se colocó la estatua? (En número) 1994 2. Fuente del Cisne La Fuente del Cisne, en la zona llamada “La Pérgola” del parque Campo Grande de Valladolid, fue proyectada por Gonzalo Bayón en 1887. El pilón circular está adornado con escudos de Valladolid y una inscripción que recuerda el año de su construcción. En su centro se alza un macizo del que surgen seis náyades, que sostienen en sendas manos peces que parecen lanzar al agua. La composición está coronada por la figura de un cisne con sus alas extendidas. Dentro del estanque y a su alrededor hay tritones que arrojan agua al conjunto central. ¿Cuántos peces se encuentran en la fuente? (En número) 6 3. Lago Creado en 1879 por Ramón Oliva. El estanque está formado por dos islas y una montaña artificial imitando a una gruta de la que caía una cascada. En el estanque hay mucha vida animal, entre los que encontramos cisnes, patos, peces y reptiles. ¿Cuál era el mote del barquero? El Catarro 4. Fuente de la fama Fuente monumental proyectada por Antonio Iturralde y del escultor Mariano Chicote, erigida en 1883 en el centro de los jardines del Campo Grande, como homenaje a uno de los alcaldes de mayor trascendencia para la historia de Valladolid. ¿A quién está dedicada la fuente? Miguel Íscar 5. Pajarera Construida en los años treinta del siglo pasado. Tiene un diseño que adquiere un aire oriental de concepción modernista y se ha convertido en el epicentro de la vida animal que habita en el parque. Observando la pantalla que se encuentra en un lateral de la pajarera, nombra un ave que empiece por “P” y se encuentre en la pajarera del Campo Grande. periquito Tabla B.2: Actividad educativa naranja 114 APÉNDICE B. PLANTILLAS DE ACTIVIDADES Figura B.2: Mapa de la plantilla educativa naranja. B.3. Actividad de tipo deportiva Las plantillas de tipo “deportiva” no muestran ningún reto a los participantes al alcanzar las balizas. Tan solo tienen que alcanzarlas en el menor tiempo posible, como en una carrera de orientación normal. La plantilla de tipo “deportiva” que hemos creado consta de siete balizas: 1. Poeta L. Cano 2. Ciprés 3. Castaño de indias (puerta) 4. Chopo 5. Casa de los jardineros 6. Busto de Miguel Íscar 7. Escudo floral de Valladolid 115 APÉNDICE B. PLANTILLAS DE ACTIVIDADES Figura B.3: Mapa de la plantilla deportiva. 116 Apéndice C Manual de instalación Para instalar la aplicación se necesita disponer del archivo ejecutable (.apk) descargado en un dispositivo Android, cuya versión no debe ser inferior a Android 8. Luego basta con seguir los pasos que se describen a continuación en la Figura C.1. Figura C.1: Pasos para instalar la aplicación. A la hora de descargar el archivo apk puede que haya que aceptar una autorización como la que aparece en la Figura C.2. 117 APÉNDICE C. MANUAL DE INSTALACIÓN Figura C.2: Autorizar la descarga de la aplicación. 118