Aplicación web de soporte al Aprendizaje-Servicio

Aplicación web de soporte al Aprendizaje-Servicio Web application for supporting Service-Learning UNIVERSIDAD COMPLUTENSE DE MADRID FACULTAD DE INFORMÁTICA TRABAJO DE FIN DE GRADO Autores: Carlos García Vaquero (Doble Grado en Ingeniería de Informática y ADE) Feiyun Ye (Grado en Ingeniería Informática) Shuyi Wang (Grado en Ingeniería de Software) Directores: Manuel Montenegro Montes Simon Pickin Curso académico 2022-2023 Agradecimientos Queremos agradecer profundamente a nuestros tutores, Manuel y Simón, por el tiempo que han invertido en nuestra formación y por las valiosas orientaciones que nos han proporcionado, especialmente en la etapa de desarrollo del proyecto. Además, nos gustaría mostrar nuestro agradecimiento a nuestros compañeros y familiares, quienes nos han brindado su apoyo incondicional a lo largo de todo el curso académico. Reciban todos ustedes nuestro más sincero agradecimiento. 2 Índice de contenidos Agradecimientos 2 Índice de figuras 6 Enlace al código fuente 7 Resumen 8 Palabras clave 9 Abstract 10 Keywords 11 Capítulo 1.Introducción 12 1.1. Antecedentes 12 1.2. Objetivos 13 1.3. Plan de trabajo 16 Capítulo 2.Introduction 19 2.1. Background 19 2.2. Objectives 20 2.3. Workplan 22 Capítulo 3.Estado del arte / Antecedentes 25 3.1. Introducción al contexto de la propuesta 25 3.2. Antecedentes y TFGs predecesores 25 Capítulo 4.Tecnologías utilizadas 27 4.1. Node.js 27 4.2. Angular 27 4.3. Docker 28 4.4. Express.js 28 4.5. Git 29 4.6. Github 29 4.7. Modelio 29 4.8. Trello 30 4.9. phpMyAdmin 30 4.10. PuTTY 30 4.11. Docker-compose 30 4.12. Xbox Game Bar 31 4.13. Microsoft Excel 31 4.14. Google Forms 31 3 Capítulo 5.Creación de partenariados 33 5.1. Itinerario A 42 5.2. Itinerario B 45 5.3. Itinerario C 48 Capítulo 6.Despliegue de la aplicación 50 6.1. Acceso al servidor 50 6.2. Docker rootless 51 6.3. Despliegue del front-end 51 6.4. Mantener el servidor en funcionamiento 52 6.5. Despliegue de la base de datos 53 Capítulo 7.Experiencia de usuario 54 7.1. Introducción 54 7.2. Propósitos y objetivos de evaluación 55 7.3. Preguntas de investigación 55 7.4. Requisitos de los participantes 56 7.5. Diseño experimental 57 7.5.1. Flujos de trabajo de los usuarios 57 7.5.2. Entornos y herramientas a utilizar 58 7.5.3. Tareas del moderador 60 7.5.4. Datos que se van a recolectar y metodología de análisis de datos 61 7.6. Preparación del entorno de evaluación 62 7.7. Búsqueda y selección de los participantes 62 7.8. Materiales para las sesiones de evaluación 63 7.8.1. Guión para el moderador 63 7.8.2. Guión para el usuario 64 7.9. Análisis de datos 67 7.9.1. Análisis de las métricas de la interacción 68 7.9.2. Análisis de los comentarios durante la interacción y entrevistas 79 7.9.3. Análisis de los cuestionarios 88 7.10. Informe de hallazgos y recomendaciones 97 7.11. Resultados de investigación 105 Capítulo 8.Conclusiones y trabajo futuro 109 8.1 Conclusiones 109 8.2. Problemas encontrados 112 8.3. Trabajo futuro 112 Capítulo 9.Conclusions and future work 114 9.1. Conclusions 114 8.2. Problems encountered 116 8.3. Future work 117 4 Capítulo 10.Contribuciones al proyecto 118 10.1. Carlos García Vaquero 118 10.2. Feiyun Ye 120 10.3. Shuyi Wang 122 Bibliografía y referencias 125 Apéndice 1.Corrección de bugs de TFGs anteriores 126 Apéndice 2.Cuestionario 130 Apéndice 3.Desarrollo de las sesiones de evaluación por usuario 133 5 Índice de figuras Figura 5.1. Lista de notificaciones 33 Figura 5.2. Notificación de oferta aceptada 34 Figura 5.3. Visualización del perfil de un socio comunitario 35 Figura 5.4. Modal de notificación 35 Figura 5.5. Mensaje de coincidencias 36 Figura 5.6. Información detallada de una notificación de matching 36 Figura 5.7. Información detallada de un partenariado 37 Figura 5.8. Lista de partenariados 37 Figura 5.9. Formulario de partenariado completo 39 Figura 5.10. Diagrama del proceso en BPMN 40 Figura 5.11. Diagrama de subproceso de creación de un partenariado 41 Figura 5.12. Diagrama de subproceso de aprobación de la creación de un partenariado 41 Figura 5.13. Ventana modal de la aceptación de una oferta 42 Figura 5.14. Información detallada de una petición aceptada 43 Figura 5.15. Información detallada de un partenariado 43 Figura 5.16. Lista de notificaciones con partenariado creado 44 Figura 5.17. Información detallada de petición rechazada 44 Figura 5.18. Información detallada de una demanda. 45 Figura 5.19. Formulario a rellenar para creación de partenariado 46 Figura 5.20. Ventana modal de petición enviada 46 Figura 5.21. Información detallada de la oferta 47 Figura 5.22. Modelo de dominio ampliado con Notificaciones. 49 6 Enlace al código fuente https://github.com/ucm-aps/tfg-aps https://github.com/ucm-aps/tfg-aps-configuration 7 Resumen Nos referimos a un proyecto ApS como una práctica académica que combina procesos de aprendizaje y servicio a la comunidad con el fin de ayudar al alumnado a implicarse en los proyectos y actividades de su entorno. La aplicación en la que se centra el desarrollo del presente TFG se ideó en el TFG de la UNED de Lozano [9] y la elección de las principales tecnologías usadas en la aplicación actual se hizo en el marco del TFG de la UNED de Alonso [11]. Casar una oferta con una demanda de ApS era un proceso costoso, y por eso los profesores concurrieron con la necesidad de tener un soporte informático para facilitar este proceso. Esta necesidad se convirtió en una propuesta que acabó siendo el TFG a día de hoy, un proyecto web que busca cumplir las necesidades de las dos partes. Partiendo de las versiones de los TFG anteriores, nuestro objetivo es terminar las funcionalidades pendientes relativas a los procesos previos a la creación de un proyecto ApS, tener terminado el objetivo principal del proyecto, la de poder crear un partenariado a partir de las ofertas y las demandas existentes. Otro objetivo consiste en implementar un sistema de notificaciones que notifique a los distintos usuarios implicados sobre los cambios de estado relevantes en los procesos, además de un estudio de experiencia de usuario tras desplegar la aplicación. Sobre las tecnologías utilizadas, en este TFG hemos continuado con las tecnologías utilizadas en las versiones anteriores: Angular, Express.js, Node.js, JavaScript y MySQL. 8 Palabras clave ● Proyecto web ● Comunidad virtual ● Plataforma educativa ● Gestión de proyectos ● Emparejamiento ● Aprendizaje-Servicio ● Evaluación ● Participación comunitaria 9 ● Experiencia de usuario. Una vez se cumplan los objetivos relacionados con la implementación, el desarrollo y el despliegue de la aplicación, se realizará una experiencia de usuario, con los propósitos de evaluar la utilidad y la usabilidad de la herramienta. Para conocer los objetivos específicos de la experiencia, consultar el epígrafe de propósitos y objetivos de evaluación en el capítulo de la experiencia de usuario. 1.3. Plan de trabajo Una vez que se definieron los objetivos para este curso, decidimos emplear Trello como herramienta de gestión de proyectos para organizar y coordinar las tareas a realizar. Trello es una plataforma versátil y eficiente que permite gestionar proyectos utilizando el enfoque Kanban [1], un método de administración de la producción originado en Japón. El método Kanban se basa en la creación de tarjetas que representan tareas individuales, las cuales se asignan a los miembros del equipo y se organizan en diferentes columnas, representando distintas etapas del proceso de trabajo. Podemos dividir el trabajo realizado en este curso en las siguientes fases: ● Durante la primera fase, que tuvo lugar en el mes de septiembre, nos hemos enfocado en comprender la naturaleza de los proyectos ApS y en revisar las memorias de cursos anteriores para obtener una mejor perspectiva acerca de la aplicación web en la que trabajaremos. Al mismo tiempo, nos vimos en la necesidad de investigar de manera autónoma las tecnologías que se emplearían en este proyecto, ya que eran desconocidas para todos los integrantes del equipo. Esta etapa inicial nos permitió adquirir un conocimiento sólido sobre los proyectos ApS y familiarizarnos con las tecnologías esenciales para el desarrollo de nuestra aplicación web. ● La segunda etapa tuvo lugar entre el 23 de octubre y el 2 de noviembre de 2022. Durante este período, iniciamos la instalación local del proyecto, enfrentando ciertos desafíos, ya que se empleaba Docker como tecnología clave y era nuestra primera experiencia con ella. En esta fase, nos enfocamos en familiarizarnos con Docker y en comprender cómo se integraba en el proyecto. A pesar de las dificultades iniciales, logramos superar los obstáculos y adquirir conocimientos valiosos sobre esta tecnología, lo que nos permitió realizar una instalación local exitosa y avanzar con las pruebas de la aplicación web. ● La tercera fase se extendió desde el 2 de noviembre hasta el 12 de noviembre de 2022. Durante esta etapa, nos dedicamos a analizar minuciosamente el código del proyecto. Esta tarea resultó ser desafiante debido a que el código incluía elementos de múltiples versiones anteriores, lo cual aumentaba la complejidad de la evaluación. Para abordar esta situación, realizamos un chequeo de las funcionalidades implementadas y de aquellas que aún no se habían completado. Esto nos permitió identificar áreas específicas que requerían atención y trabajo adicional en las siguientes fases del proyecto. Además, este análisis en profundidad nos proporcionó una visión clara de las mejoras y modificaciones necesarias en el 16 código existente, así como de las funcionalidades que debían ser priorizadas en el proceso de desarrollo. ● La cuarta fase tuvo lugar desde el 12 de noviembre hasta el 26 de noviembre de 2022. Durante este período, nos centramos en la implementación de los elementos requeridos para la creación exitosa de partenariados. Para lograr esto, llevamos a cabo varias tareas, incluyendo la creación y expansión de las tablas necesarias en la base de datos. También trabajamos en la creación de relaciones entre las distintas entidades involucradas en los partenariados, como socios comunitarios y profesores, para garantizar un flujo de trabajo coherente y efectivo dentro de la plataforma. Este proceso de implementación, así como los detalles técnicos asociados, se desarrollan con mayor profundidad en el capítulo 5 de esta memoria. ● La quinta fase se llevó a cabo entre el 26 de noviembre del 2023 al 8 de febrero del 2023. Durante este período, nos enfocamos en la implementación de la primera modalidad para la creación de partenariados, en la que un socio comunitario acepta una oferta publicada por un profesor. Al aceptar la oferta, se envía una notificación al profesor, quien puede aprobar o rechazar la propuesta de partenariado. Mientras trabajábamos en esta modalidad de creación de partenariados, también nos dedicamos al desarrollo del sistema de notificaciones. Este sistema es fundamental para mantener a todas las partes involucradas informadas sobre las actualizaciones y cambios en los partenariados, asegurando una comunicación eficiente y efectiva entre profesores y socios comunitarios. Este proceso de implementación, así como los detalles técnicos asociados, se desarrollan con mayor profundidad en el capítulo 5.1 de esta memoria. ● La sexta fase del proyecto tuvo lugar entre el 8 de febrero de 2023 al 1 de marzo de 2023. Durante este período, nos enfocamos en implementar la segunda modalidad de creación de partenariados. Esta modalidad consiste en que un profesor respalda una demanda de servicio presentada por un socio comunitario, lo que da lugar a la formación de un partenariado. A lo largo de esta fase, también dedicamos tiempo a reflexionar sobre cómo abordar la implementación de la tercera modalidad de creación de partenariados. Esta modalidad implica el emparejamiento automático de ofertas y demandas de servicio, basado en el algoritmo de matching desarrollado previamente en otro proyecto. Paralelamente, se comenzaron los preparativos de la futura experiencia de usuario que se realizaría en fases sucesivas. Este proceso de implementación, así como los detalles técnicos asociados, se desarrollan con mayor profundidad en el capítulo 5.2 de esta memoria. ● La séptima fase del proyecto se llevó a cabo desde el 1 de marzo hasta el 30 de marzo. En esta etapa, nos centramos en completar la implementación de la tercera modalidad de creación de partenariados. Esta modalidad consiste en el emparejamiento automático de ofertas y demandas de servicio, utilizando el algoritmo de matching desarrollado en trabajos previos. Una vez finalizada la implementación de esta modalidad, nos enfocamos en el despliegue del trabajo en el servidor proporcionado por la UNED. Además, se comenzó a planificar la experiencia de usuario, planteando los propósitos, los objetivos y las preguntas de investigación de la misma. Este proceso de implementación, así como los detalles 17 técnicos asociados, se desarrollan con mayor profundidad en los capítulos 5.3 y 6 de esta memoria. ● En la octava fase del proyecto, del 1 de abril al 1 de mayo, nos centramos en pulir y perfeccionar el sistema, abordando cualquier problema o inconsistencia que pudiera surgir. Nuestro objetivo era corregir errores y solucionar cualquier inconveniente que hubiéramos encontrado durante el desarrollo y las pruebas de la aplicación. Por otra parte, se terminó de diseñar la planificación de la experiencia de usuario, concretando los requisitos de los participantes y comenzando a realizar el diseño experimental, definiendo las tareas del moderador, describiendo el entorno y las herramientas que se iban a utilizar y explicando la metodología de análisis de datos. Este proceso se desarrolla con mayor profundidad en el capítulo 7 de esta memoria. ● En la novena fase del proyecto, del 1 de mayo al 17 de mayo, se comenzó con la búsqueda y selección de los participantes y se definieron los flujos de trabajo para el socio comunitario y para el profesor, y se pobló la base de datos con ofertas y demandas de ejemplo. Durante los días 12, 16 y 17 de mayo tuvieron lugar las sesiones de evaluación a los usuarios. Este proceso se desarrolla con mayor profundidad en el capítulo 7 de esta memoria. ● En la fase final del proyecto, se llevó a cabo el análisis de los datos obtenidos de las sesiones de evaluación, se elaboró la lista de problemas encontrados en la aplicación y se extrajeron las conclusiones de la experiencia de usuario. Además, nos dedicamos a documentar el proceso de desarrollo, los desafíos enfrentados, las soluciones adoptadas y los resultados obtenidos en la memoria del trabajo. Estos procesos se desarrollan en los capítulos 8 y en el apéndice 2 y 3 de esta memoria. 18 Capítulo 2 Introduction The main objective of the project is to complete and extend the prototype developed in the previous TFGs, that is, in the creation of a web platform to support the search for partners between university professors and third sector or public sector organizations, and the subsequent definition and realization of Service-Learning projects. 2.1. Background This work is part of the TFG of Sergio Arroyo Galán, Yrving David Conde Cubas and Dorta Yagüe, supervised by Manuel Montenegro and Simon Pickin. Technologies such as Node.js, Angular, Express and MySQL were used following the requirements provided by the directors. The purpose of the web platform in this project is to facilitate the creation, administration and evaluation of ApS projects. In an ApS project, students apply theoretical knowledge in real situations to help their community. These activities are proposed and managed, on the one hand, by teachers and, on the other hand, by community partners. The latter are entities (companies, non-governmental organizations, etc.) interested in these projects. At the end of the ApS project, students are evaluated and encouraged to reflect on their services, seeking to strengthen their solidarity and ethics. In ApS projects, reaching an agreement between teachers and community partners represents a challenge, since they have different perspectives of the project. This problem, present even when both parties want to carry out the same project, led teachers to propose a similar initiative in 2004. A more detailed explanation of ApS projects can be found in chapter 3. In the field of Service-Learning (ApS), several predecessor Final Degree Projects (TFG) have been carried out that have laid the foundations for the development of this project. Professors with experience in ApS initiatives have concluded that an adequate computer tool would be very useful to match offers and demands in this field. This need led to the development of several TFGs, whose main objective was to create a web application to support the ApS using technologies such as Node.js. This work laid the foundations for this TFG, which seeks to improve and expand the existing functionalities in the previous prototype. Throughout the development of this project, the restrictions and technological decisions taken in the predecessor TFGs have been taken 19 into account, such as the justification for the change from a documentary database (Mongo) to a relational database (MySQL). In addition, other similar approaches and applications have been investigated in the field of ApS, such as experience repositories and previous projects, from which they have learned and, in some cases, code has been reused. 2.2. Objectives Starting from the previous works, our main objective in this TFG is to continue with the previous works, remodeling and extending the database, redesigning the application and implementing new views, and finishing the main functionalities prior to the creation of an ApS project. so that this web application can have a basic functionality when it is deployed. As previously conceived, the web application that is the object of this work would consist of various components organized into two large subsystems: ●Support for the creation of partnerships and ApS projects:This subsystem would aim to provide a platform that facilitates the formation of collaborations between different actors to carry out Service-Learning (ApS) projects. This would imply providing functionalities for the publication of offers and demands, the creation of partnerships and the management of projects. ●Support for ongoing ApS projects (in particular, student assessment):This subsystem would be in charge of providing the necessary tools for monitoring and managing ApS projects once they are underway. This would include the implementation of evaluation systems for the students, the monitoring of the progress of the project and the communication between the members of the partnership. We can divide the first large subsystem into five subsystems, which are described in greater detail below: 1. Subsystem of notifications:This subsystem is fundamental in the management of communications associated with the creation of partnerships, offers and demands. It is responsible for notifying relevant users about the evolution of the different stages of the process, improving communication between teachers, community partners and students. 2. Offer and Demand Subsystem:This goal focuses on establishing strong and effective connections between offers accepted by community partners and demands supported by teachers. With this, it seeks to improve the efficiency in the assignment of projects and guarantee a greater correspondence between the needs of the community partners and the capacities and abilities of the professors and students involved. 3. Partnership subsystem:This component, of great importance in the process, is dedicated to facilitating negotiation and the exchange of information between teachers and community partners once a connection between a supply and a demand has been established. The subsystem allows both parties to adjust the details of the partnership and, subsequently, modify the status of the partnership 20 according to the progress made. This approach allows greater control and monitoring of ongoing partnerships. 4. Matching subsystem:This objective seeks to continue the previous work of colleagues from previous courses, in order to automate the process of linking offers and demands. This will be achieved through the matching algorithm implemented by TFG colleagues from past courses, which facilitates the optimal matching of offers and requests based on specific criteria, such as areas of interest and availability, among others. 5. Subsystem of projects:The purpose of this component is to take the negotiated partnerships to the next level, turning them into concrete and viable projects. In addition, the roles of the students in the process will be integrated, allowing their active participation in the planning, execution and evaluation of the projects. This will encourage a more collaborative approach and allow students to gain practical and applied skills in their field of study. Based on these components, our main objectives for this Final Degree Project are listed in the following points: ●Implementation of a notification system.This notification system will allow all users involved to stay informed about the progress of offers, demands and partnerships, thus facilitating decision-making, collaboration and coordination in real time. In addition, by providing detailed and up-to-date information, greater transparency in the process is guaranteed and misunderstandings and confusion are avoided. ●Implementation of views to display notifications.These views contain relevant information, such as the acceptance of offers, support of demands, creation of partnerships or the discovery of matches between offers and demands. Additionally, notifications are intuitively organized and attractively presented for easy navigation and user interaction. ●Implementation of the appropriate logic for the management of offers and demands.It is an essential aspect in the development of the application. In previous releases, it had been noted that both teachers and community partners had the ability to create and fill out offer and request forms. However, this approach did not align with the requirements. To address this situation and improve the efficiency in the management of offers and demands, a review and update of the logic of the system has been carried out. Now, it has been established that only teachers have the facility to create offers, and that only community partners can generate demands. This segmentation in the responsibilities and actions allowed to each user ensures a more adequate distribution of the tasks and a better correspondence between the needs of the community partners and the capacities of the teachers. ●Implementation of profile view to know who has accepted an offer or who has supported the demand.This functionality has been developed with the objective of providing basic personal information of the issuer of the notification, thus facilitating interaction and collaboration between the different actors involved in the process. In addition, having detailed information on who has accepted an offer or supported a 21 demand encourages the creation of relationships of trust and facilitates the establishment of solid and successful partnerships. ●Implementation of the form and all the flows for the creation of a partnership. Forms have been developed to facilitate the creation of partnerships through the interaction between offers and demands. This process allows for the establishment of collaborations between teachers and community partners through three different modalities: ○ The approval of an offer by the community partner, originated by the proposal of an internal professor. ○ The endorsement by a teacher of a lawsuit filed by a community partner. ○ Automatic matching between a service proposal made by a teacher and a service request made by a community partner. This pairing is carried out using the matching algorithm implemented in the Final Degree Projects[3] of previous years. ●Expansion of the domain model and the data model.Initially established in the previous Final Degree Project [4], with the aim of including the modeling of the subsystem of active projects. This expansion of the models will allow a better integration between the previously mentioned subsystems. This improvement in the domain and data models provides a solid foundation for the development and implementation of additional functionality in the active projects subsystem. ●Correction of bugs found in the TFG of previous versions.They are detailed in more detail in Appendix 1. ●Deployment on the UNED website.All these efforts have as their main objective to create a functional and accessible web application for the community. To achieve this, a basic version has been deployed on the institution's server, which includes the functionalities implemented so far. As the development and refinement of the project progresses, updates and improvements will continue to be made to offer a robust and efficient tool to users. ● User experience. Once the objectives related to the implementation, development and deployment of the application are met, a user experience will be carried out, with the purpose of evaluating the usefulness and usability of the tool. To find out the specific objectives of the experience, consult the section on evaluation purposes and objectives in the user experience chapter. 2.3. Workplan Once the objectives for this course were defined, we decided to use Trello as a project management tool to organize and coordinate the tasks to be carried out. Trello is a versatile and efficient platform that allows you to manage projects using the Kanban approach, a production management method originating in Japan. 22 The Kanban method is based on the creation of cards that represent individual tasks, which are assigned to team members and are organized in different columns, representing different stages of the work process. We can divide the work done in this course into the following phases: ● During the first phase, which took place in September, we have focused on understanding the nature of ApS projects and reviewing previous course reports to gain a better perspective on the web application on which we will work. At the same time, we found ourselves in the need to independently investigate the technologies that would be used in this project, since they were unknown to all the members of the team. This initial stage allowed us to gain a solid understanding of ApS projects and familiarize ourselves with the essential technologies for the development of our web application. ● The second stage took place between October 23 and November 2, 2022. During this period, we started the local installation of the project, facing certain challenges, since Docker was used as a key technology and it was our first experience with it. In this phase, we focused on becoming familiar with Docker and understanding how it was integrated into the project. Despite initial difficulties, we were able to overcome obstacles and gain valuable insights into this technology, allowing us to successfully install locally and move forward with testing the web application. ● The third phase lasted from November 2 to November 12, 2022. During this phase, we dedicated ourselves to thoroughly analyze the code of the project. This task proved challenging because the code included elements from multiple previous versions, which added to the complexity of the test. To address this situation, we carried out a check of the implemented functionalities and those that had not yet been completed. This allowed us to identify specific areas that required additional attention and work in subsequent phases of the project. In addition, this in-depth analysis gave us a clear view of the necessary improvements and modifications to the existing code, as well as the functionalities that needed to be prioritized in the development process. ● The fourth phase took place from November 12 to November 26, 2022. During this period, we focused on implementing the elements required for successful partnership building. To accomplish this, we perform several tasks, including creating and expanding the necessary tables in the database. We also work on the creation of relationships between the different entities involved in the partnerships, such as community partners and teachers, to guarantee a coherent and effective workflow within the platform. This implementation process, as well as the associated technical details, are developed in greater depth in chapter 5 of this report. ● The fifth phase was carried out between November 26, 2023 and February 8, 2023. During this period, we focused on the implementation of the first modality for the creation of partnerships, in which a community partner accepts a published offer by a teacher. Upon acceptance of the offer, a notification is sent to the teacher, who can approve or reject the partnership proposal. While we were working on this form of partnership creation, we also worked on the development of the notification system. 23 This system is critical to keeping all parties involved informed of partnership updates and changes, ensuring efficient and effective communication between faculty and community partners. This implementation process, as well as the associated technical details, are developed in greater depth in chapter 5.1 of this report. ● The sixth phase of the project took place from February 8, 2023 to March 1, 2023. During this period, we focused on implementing the second modality of partnership creation. This modality consists of a teacher supporting a demand for service presented by a community partner, which gives rise to the formation of a partnership. Throughout this phase, we also spend time reflecting on how to approach the implementation of the third modality of partnership building. This modality implies the automatic matching of service offers and requests, based on the matching algorithm previously developed in another project. At the same time, preparations for the future user experience began, which would be carried out in successive phases. This implementation process, as well as the associated technical details, are developed in greater depth in chapter 5.2 of this report. ● March 30. At this stage, we focus on completing the implementation of the third modality for creating partnerships. This modality consists of the automatic matching of service offers and demands, using the matching algorithm developed in previous works. Once the implementation of this modality is finished, we focus on the deployment of the work on the server provided by the UNED. In addition, the user experience began to be planned, setting out its purposes, objectives and research questions. This implementation process, as well as the associated technical details, are developed in greater depth in chapters 5.3 and 6 of this report. ● In the eighth phase of the project, from April 1 to May 1, we focused on polishing and refining the system, addressing any issues or inconsistencies that might arise. Our goal was to fix bugs and fix any issues we encountered during app development and testing. On the other hand, the planning of the user experience was completed, specifying the requirements of the participants and beginning to carry out the experimental design, defining the tasks of the moderator, describing the environment and the tools that were going to be used and explaining the data analysis methodology. This process is developed in greater depth in chapter 7 of this report. ● In the ninth phase of the project, from May 1 to May 17, the search and selection of the participants began and the workflows for the community partner and the teacher were defined, and the database was populated with Sample offers and requests. User evaluation sessions took place on May 12, 16 and 17. This process is developed in greater depth in chapter 7 of this report. ● In the final phase of the project, the analysis of the data obtained from the evaluation sessions was carried out, the list of problems found in the application was prepared and the conclusions of the user experience were drawn. In addition, we are dedicated to documenting the development process, the challenges faced, the solutions adopted and the results obtained in the work memory. These processes are developed in chapters 8 and in appendix 2 and 3 of this report. 24 Capítulo 3 Estado del arte / Antecedentes 3.1. Introducción al contexto de la propuesta El ApS, según Barbara Jacoby [2], es una forma de educación basada en la experiencia en la que los estudiantes participan en actividades que abordan diversos aspectos, como los derechos humanos o las necesidades de una comunidad, junto con oportunidades para la reflexión y el logro de los resultados de aprendizaje deseados. La experiencia en la implementación de iniciativas de Aprendizaje-Servicio (ApS) en España revela una barrera significativa [3]: la dificultad para alinear la oferta, es decir, las capacidades y recursos educativos disponibles, con la demanda, las necesidades de las organizaciones o comunidades que podrían beneficiarse de estos servicios. Esta complejidad ha impedido que muchos proyectos potenciales de ApS se realicen. Los profesores con experiencia en iniciativas ApS, tanto a nivel local como en proyectos de cooperación internacional para el desarrollo, reconocieron que un soporte informático adecuado podría ser instrumental para superar este desafío. Una plataforma de este tipo facilita la identificación de partenariados potenciales y promovería la colaboración entre los proveedores de servicios y los beneficiarios potenciales. Esto permitiría refinar las ideas iniciales en propuestas de proyectos realistas y viables que satisfagan las necesidades de ambas partes. Además, esta plataforma digital podría proporcionar orientación y coordinación durante las diferentes etapas de los proyectos ApS en curso, ofreciendo un marco formal para su desarrollo. De este modo, se promovería la aplicación sistemática y rigurosa de las metodologías de ApS. Además, esta herramienta facilita el seguimiento de los aprendizajes, la evaluación continua de los alumnos, y el seguimiento y evaluación de los proyectos en sí, mejorando la eficiencia y efectividad de los proyectos ApS. 3.2. Antecedentes y TFGs predecesores A lo largo de los años, se han realizado varios intentos para desarrollar una aplicación informática para facilitar el proceso de Aprendizaje-Servicio (ApS). Hasta donde sabemos, el primer intento de construir una aplicación de este tipo fue realizado en el contexto del Proyecto Fin de Carrera de Parmentier [8] en la Universidad Politécnica de Madrid, produjo una aplicación web basada en el Sistema de Gestión de Contenidos (CMS) Plone. Sin embargo, debido a la necesidad de recursos humanos para su administración y despliegue, nunca se puso en uso. Posteriormente, los profesores de la Universidad Complutense de Madrid y la Universidad Nacional de Educación a Distancia (UNED) retomaron esta idea, ofreciendo un 25 además de permitir la incorporación de elementos visuales y la personalización del diseño para adaptarse a las necesidades específicas del proyecto. En nuestro caso, decidimos utilizar Google Forms para llevar a cabo los cuestionarios a los usuarios durante la fase de evaluación. Esta decisión se tomó por varias razones. En primer lugar, Google Forms es una herramienta de fácil acceso y uso, lo que facilitó la participación de los usuarios en las sesiones de evaluación. Además, la posibilidad de recoger respuestas en tiempo real y la integración automática con Google Sheets para el análisis de los datos recogidos fueron factores determinantes para la elección de esta herramienta. 32 Capítulo 5 Creación de partenariados En este capítulo, exploramos el flujo de trabajo para la creación de un partenariado, y explicaremos también la implementación de varias características clave, que incluyen la página de notificaciones, la página detallada de una notificación, la página de perfil, la página modal de notificaciones, la página de coincidencias (matching), la página detallada de un partenariado, la lista de partenariados y el formulario de partenariado. ● Lista de notificaciones: Esta página muestra una lista de todas las notificaciones que un usuario ha recibido. Las notificaciones se presentan en orden cronológico, desde la más antigua hasta la más reciente. Los usuarios pueden desplazarse por la lista para ver todas sus notificaciones. Figura 5.1. Lista de notificaciones ● Página Detallada de una Notificación: La página se diseñó para ser dinámica y adaptarse a diferentes tipos de notificaciones. Aquí se detalla cómo se presenta cada tipo de notificación: ○ Oferta Aceptada: Cuando un socio acepta una oferta, la notificación incluye información relevante sobre el socio (que enlaza con su perfil de usuario), el título de la oferta (que enlaza con la página detallada de la oferta), y un mensaje. Además, se proporcionan dos botones para que el usuario pueda aceptar o rechazar la oferta directamente desde la notificación. ○ Partenariado Creado: Esta notificación se genera cuando se crea un nuevo partenariado. Contiene un mensaje informando de la creación del partenariado y un botón que enlaza a la página detallada del partenariado. ○ Demanda Respaldada: Cuando un profesor respalda una demanda, la notificación muestra información sobre el profesor, el título de la demanda y 33 un mensaje personalizado. Además, se proporciona un botón que permite al usuario completar el partenariado y la oferta. Tanto la demanda como la oferta están enlazadas a sus respectivas páginas detalladas. ○ Petición Rechazada: En el caso de que un profesor rechace a un socio, la notificación incluirá información sobre la oferta, el profesor y un mensaje personalizado. ○ Matching: Cuando el sistema detecta una coincidencia entre dos anuncios, se genera una notificación que incluye un botón para aceptar la coincidencia. Cada tipo de notificación está diseñado para proporcionar al usuario toda la información necesaria para tomar una decisión informada y facilitar la interacción con la aplicación. Figura 5.2. Notificación de oferta aceptada ● Página de Perfil: Esta página permite a los usuarios visualizar su perfil. Los usuarios pueden ver su información personal, incluyendo su nombre, correo electrónico, y otros detalles relevantes. 34 Figura 5.3. Visualización del perfil de un socio comunitario ● Página Modal de Notificaciones: Esta página permite a los usuarios visualizar sus notificaciones sin tener que abandonar la página actual en la que se encuentran. Figura 5.4. Modal de notificación 35 ● Mensaje de Coincidencias (Matching): Este mensaje de notificación muestra las ofertas y demandas que se han emparejado. El profesor puede ver los detalles de las ofertas y demandas emparejadas, y tienen la opción de aceptar las coincidencias sugeridas. Figura 5.5. Mensaje de coincidencias Figura 5.6. Información detallada de una notificación de matching ● Página Detallada de un Partenariado: Esta página proporciona detalles adicionales sobre un partenariado específico. Los usuarios pueden ver información sobre el socio, el profesor, la oferta y la demanda asociada al partenariado. Además hemos añadido un botón de Whatsapp con el fin de proporcionar al usuario una opción de chat con el miembro involucrado. 36 Figura 5.7. Información detallada de un partenariado ● Listado de Partenariados: Esta página muestra una lista de todos los partenariados que un usuario ha establecido. Los usuarios pueden desplazarse por la lista para ver todos sus partenariados. Figura 5.8. Lista de partenariados ● Formulario de Partenariado: Este formulario permite a los usuarios establecer un partenariado. Dependiendo de quién inicie el partenariado, la información requerida variará. Por ejemplo, si un profesor acepta a un socio, sólo se mostrará la 37 información de la oferta. Si un socio acepta el respaldo de un profesor, se mostrará la información de ambas, oferta y demanda. Si un profesor respalda una demanda, se mostrará la información de ambos anuncios, pero faltará completar la información de la oferta. Si un socio completa la demanda después de que el profesor lo haya aceptado, se mostrará la información de ambos anuncios. 38 Figura 5.9. Formulario de partenariado completo 39 Todas estas implementaciones han servido para poder desarrollar los itinerarios A, B y C que están definidos en el diagrama de flujo especificado por los compañeros del TFG anterior y explicadas a continuación. [4] Para implementar estos itinerarios, además se han tenido que extraer informaciones de oferta y demanda desde DAODemanda y DAOoferta y notificaciones para poder guardar las informaciones necesarias como el id del usuario, id de oferta, id de demanda, etc. Figura 5.10. Diagrama del proceso en BPMN. Fuente: [4] 40 Figura 5.11. Diagrama de subproceso de creación de un partenariado. Fuente: [4] Figura 5.12. Diagrama de subproceso de aprobación de la creación de un partenariado. Fuente: [4]. 41 5.3. Itinerario C El itinerario C pasa por la rama de abajo de la Figura 5.10 y luego por la rama de abajo de la Figura 5.11. Se centra en el funcionamiento del sistema de los emparejamientos. Se crea un partenariado como consecuencia de un emparejamiento automático por el algoritmo de matching [3]: 1. Emparejamiento Automático de Anuncios: En este primer paso, el sistema identifica automáticamente posibles emparejamientos entre las ofertas y demandas. Este proceso se implementa mediante algoritmos de coincidencia que se basan en varios criterios predeterminados, tales como categorías de interés, habilidades requeridas, y ubicación geográfica, entre otros. Estos algoritmos se implementan utilizando técnicas de procesamiento de lenguaje natural para una coincidencia más precisa. Una vez que se ha encontrado un emparejamiento, el sistema genera una notificación para el profesor. 2. Revisión del Profesor: Al recibir la notificación, el profesor tiene la opción de revisar el emparejamiento propuesto. Esta revisión se facilita con una interfaz de usuario intuitiva que presenta los detalles de la oferta y demanda emparejadas, permitiendo al profesor evaluar si la coincidencia es adecuada para sus necesidades y capacidades. El profesor tiene la libertad de aceptar o rechazar el emparejamiento. 3. Aceptación del Profesor: Si el profesor considera que el emparejamiento es adecuado, puede aceptarlo a través de la interfaz de la aplicación. Al hacerlo, el sistema registra esta decisión y se inicia el proceso de partenariado. Esta acción se maneja a nivel de base de datos, creando un nuevo registro de partenariado vinculado a las respectivas ofertas y demandas. 4. Notificación al Socio Comunitario: Después de la aceptación del profesor, el sistema genera automáticamente una notificación para el socio comunitario, informándole de que su oferta ha sido respaldada por un profesor. El socio comunitario puede revisar los detalles y decidir si desea proceder con la demanda. Esta interacción también se maneja a través de una interfaz de usuario fácil de usar y el sistema actualiza el estado de la demanda y el partenariado según la decisión del socio. Esta iteración pone de relieve el papel del sistema automatizado para facilitar el proceso de emparejamiento. Sin embargo, tanto el profesor como el socio tienen la libertad de aceptar o rechazar el emparejamiento basándose en su juicio y evaluación. Esto garantiza que ambas partes estén satisfechas con el emparejamiento antes de proceder con el partenariado y la demanda. Para todas estas implementaciones, hemos tenido que ampliar la base de datos, de forma que hemos añadido nuevas tablas y ampliado el modelo de datos del TFG anterior a la actual, añadiendo más tablas en la parte derecha de la misma, como se ve en la Figura 5.22: 48 Figura 5.22. Modelo de dominio de [4] ampliado con Notificaciones. 49 Capítulo 6 Despliegue de la aplicación En este capítulo, vamos a detallar el proceso integral de despliegue de la aplicación, que constituye una etapa esencial en el ciclo de vida del desarrollo de software. El despliegue de la aplicación es el punto culminante de todos los esfuerzos de desarrollo, ya que es el paso que permite que la aplicación, después de pasar por las etapas de diseño, desarrollo y pruebas, esté finalmente disponible y accesible para los usuarios finales. En el contexto de nuestro proyecto, el proceso de despliegue se ha llevado a cabo utilizando la herramienta Putty, que es un cliente de SSH/Telnet de código abierto y gratuito. Putty es una herramienta versátil y potente, ampliamente utilizada para acceder y gestionar servidores remotos a través de líneas de comando. Nuestra aplicación se desplegó en un servidor proporcionado por la Universidad Nacional de Educación a Distancia (UNED), accesible a través del dominio https://soporteaps.intecca.uned.es/. La elección de este servidor se basó en una serie de factores, entre los que se incluyen la fiabilidad del servidor, la facilidad de acceso y gestión, así como la seguridad y protección de los datos. El despliegue de la aplicación implicó varias tareas, entre las que se incluyen la transferencia de los archivos de la aplicación al servidor, la configuración del entorno del servidor, la instalación de las dependencias necesarias y la puesta en marcha de la aplicación en sí. Durante este proceso, con la ayuda de los directores, se encontraron y superaron una serie de desafíos, proporcionando valiosas oportunidades de aprendizaje para el equipo. En las siguientes secciones, detallaremos más a fondo las etapas y desafíos clave del proceso de despliegue de nuestra aplicación. 6.1. Acceso al servidor El uso del protocolo SSH es esencial para garantizar que la conexión al servidor remoto sea segura. SSH es un protocolo criptográfico de red que permite a los usuarios acceder de forma segura a un ordenador remoto. Ofrece una forma eficaz y segura de autenticación y cifrado de datos, lo que lo convierte en la opción preferida para la administración remota de servidores. Para establecer una conexión SSH con el servidor, utilizamos la dirección [email protected], donde XXXX es el nombre de usuario proporcionado por la UNED para acceder al servidor. Este usuario tiene los privilegios necesarios para realizar las tareas de despliegue. 50 Una vez establecida la conexión SSH, tuvimos acceso a la línea de comandos del servidor remoto. Desde aquí, pudimos transferir los archivos de la aplicación al servidor, instalar las dependencias necesarias, configurar el entorno del servidor y finalmente poner en marcha nuestra aplicación, aunque lo particular de nuestro despliegue fue que, a pesar de estar utilizando un entorno de servidor, no teníamos permisos de superusuario, lo que se convirtió en un desafío que tuvimos que superar, ya que la mayoría de las tareas de administración de servidores suelen requerir permisos de superusuario. Sin embargo, logramos superar este obstáculo mediante la búsqueda de soluciones y alternativas que se pudieran realizar sin estos permisos. Un ejemplo de esto fue la necesidad de ejecutar Docker en modo sin privilegios, también conocido como Docker Rootless. Este modo permite ejecutar Docker sin necesidad de permisos de superusuario. Aunque esta configuración puede tener ciertas limitaciones, fue suficiente para nuestras necesidades de despliegue y nos permitió continuar con el proceso. 6.2. Docker rootless Aunque se introdujo el uso de Docker por los alumnos del año pasado, siempre lo habían utilizado con permisos de superusuario para el despliegue, por lo que no tenían que enfrentarse a un despliegue real sin ser root. Docker rootless es una característica que permite ejecutar el motor de Docker como un usuario no root en el host de Docker. Esto es especialmente útil cuando no se tiene privilegios de superusuario en el servidor donde se está trabajando, como fue nuestro caso. Además, uno de los principales beneficios de usar Docker rootless es que mejora la seguridad del sistema. En un escenario normal, si un atacante logra explotar el motor de Docker, puede obtener acceso root al sistema. Pero en el modo rootless, el daño que puede hacer es limitado a lo que el usuario sin privilegios puede hacer. La configuración de Docker en modo rootless puede ser un poco más compleja que la configuración estándar, ya que se deben ajustar ciertas configuraciones del sistema y del kernel. Sin embargo, una vez configurado correctamente, Docker rootless funciona de la misma manera que un motor de Docker normal. En nuestro trabajo, fue obligado tener que utilizar Docker en modo rootless debido a las restricciones de superusuario en el servidor proporcionado por la UNED. Aunque inicialmente presentó un desafío adicional, logramos configurarlo con éxito y desplegar nuestra aplicación. Al trabajar con Docker rootless, es importante tener en cuenta que hay ciertas limitaciones. Por ejemplo, no todos los plugins de red y almacenamiento son compatibles con este modo. Sin embargo, para nuestro proyecto, estas limitaciones no fueron un obstáculo y pudimos continuar con el despliegue de nuestra aplicación sin problemas. 6.3. Despliegue del front-end El despliegue de una aplicación web implica varios pasos y consideraciones, en especial cuando se trata de una aplicación con una arquitectura de back-end yfront-end separados, como es nuestro caso. 51 Durante el desarrollo, el servidor de desarrollo de Angular, que se inicia con el comando ng serve, escucha en el puerto 4200. Este servidor de desarrollo es únicamente para el front-end de la aplicación, y cuando se realiza una petición al back-end, esta se redirige al puerto 8080, donde nuestro servidor de back-end está escuchando. Sin embargo, una vez que pasamos a producción, ya no necesitamos el servidor de desarrollo de Angular. En su lugar, debemos construir una versión de producción de nuestro front-end. Esta versión de producción consiste en una serie de archivos .html, .js y .css que se generan al ejecutar el comando npm run build. Este comando utiliza la herramienta Angular CLI para compilar el código de nuestra aplicación Angular en un formato que puede ser servido por cualquier servidor web. Estos archivos estáticos generados se colocan en el directorio dist/portal-aps. Ahora, en lugar de tener dos servidores (uno para el front-end y otro para el back-end), sólo necesitamos uno: nuestro servidor de back-end. Por lo tanto, necesitamos configurar nuestro servidor de back-end para que además de manejar las peticiones a la API, también sirva estos archivos estáticos. Para ello, redirigimos todo el tráfico al puerto 8080, que es donde nuestro servidor de back-end está escuchando. De esta forma, cuando un usuario accede a nuestra aplicación, el servidor le sirve los archivos estáticos del front-end, y cuando estos archivos hacen una petición al back-end, esta se realiza al mismo servidor, pero a una ruta diferente. 6.4. Mantener el servidor en funcionamiento Una de las dificultades a las que nos enfrentamos fue cómo mantener el servidor en funcionamiento después de salir de la sesión en la terminal de Putty. Para solucionar este problema, se utilizó el comando nohup antes del comando que arranca el servidor. El comando nohup es una utilidad en sistemas Unix y similares que permite a los comandos seguir ejecutándose después de que la terminal se haya cerrado. La sintaxis es sencilla: nohup command &, donde command es el comando que se desea ejecutar y el símbolo & indica que el proceso se ejecutará en segundo plano. En nuestro caso, si el comando para iniciar el servidor es, por ejemplo, npm start, entonces el comando que debemos ejecutar es nohup npm start &. Cuando ejecutamos un comando con nohup, la salida del comando (tanto la salida estándar como la salida de error) se redirige automáticamente al archivo nohup.out en el directorio actual. Esto significa que si hay algún problema con el comando, podemos revisar este archivo para ver cuál es el problema. Además, este comando no se detendrá cuando cerramos la terminal o cuando nos desconectamos del servidor. Esto es especialmente útil cuando necesitamos que un comando se ejecute durante un largo periodo de tiempo, como es el caso de un servidor web. Gracias a nohup, hemos podido garantizar que nuestro servidor continúa en funcionamiento incluso después de que cerramos la terminal de Putty. De esta manera, hemos logrado desplegar nuestra aplicación de manera efectiva y duradera. 52 6.5. Despliegue de la base de datos El despliegue de la base de datos se realizó en el contenedor Docker local-configuration-db-1. El contenedor local-configuration-phpmyadmin-1 se emplea únicamente como interfaz de phpMyAdmin, mientras que la base de datos real reside en local-configuration-db-1. Para acceder a MySQL en el contenedor, se ejecutó el comando: docker exec -it local-configuration-db-1 sh -c 'exec /bin/mysql aps -u xxx -p "yyy"' siendo xxx el nombre de usuario, yyy la contraseña Encontramos que la base de datos ya se encontraba creada con tablas, probablemente de la versión anterior de la aplicación. Para importar la nueva versión de la base de datos desde el archivo aps4.2.sql, fue necesario primero eliminar todas las tablas existentes con los comandos DROP DATABASE zzz; y CREATE DATABASE zzz;, siendo zzz el nombre de la base de datos. Después, se importó el archivo aps4.2.sql con el comando: docker exec -i local-configuration-db-1 sh -c 'exec /bin/mysql xxx -u xxx -p "yyy"' < ~/aps4.2.sql Este proceso creó las tablas de la última versión de la aplicación. De esta manera, la base de datos estaba lista para su uso. 53 Capítulo 7 Experiencia de usuario En este capítulo, se detalla la planificación, el análisis de los datos recogidos y los resultados obtenidos de la experiencia de usuario realizada a continuación de la implementación de la aplicación. 7.1. Introducción Las evaluaciones con usuarios representan la manera más fiable de observar cómo los usuarios finales interactúan con la interfaz, ofreciéndoles probar directamente la aplicación para comprobar si son capaces de realizar con éxito el flujo de trabajo que se les propone. Cuando hablamos de evaluaciones de la usabilidad de aplicaciones con usuarios, podemos distinguir dos tipos según sus objetivos: la evaluación de diagnóstico o la evaluación de verificación. Mientras que la primera se realiza para analizar las carencias, los puntos fuertes y los aspectos a mejorar de la aplicación, la segunda se realiza para confirmar si el proceso está obteniendo los resultados esperados. Como el desarrollo de la aplicación todavía se encuentra en una fase intermedia de implementación, consideramos que lo más lógico es realizar la evaluación desde una perspectiva formativa o de diagnóstico, pues su propósito es encontrar precisamente posibles problemas de usabilidad, que es uno de los principales motivos por los que se ha decidido realizar la experiencia con usuarios durante este curso académico. La estructura que hemos decidido para esta evaluación con usuarios consta de las siguientes etapas: Planificación de la experiencia de usuario Identificación del propósito y de los objetivos de evaluación Formulación de las preguntas de investigación Identificación de los requisitos de los participantes Descripción del diseño experimental Desarrollo de las sesiones de evaluación Preparación del entorno de evaluación Búsqueda y selección de participantes Preparación de los materiales para las sesiones de evaluación Elaboración del informe de evaluación Análisis de datos Redacción del informe de hallazgos y recomendaciones Presentación de los resultados de investigación 54 7.2. Propósitos y objetivos de evaluación El propósito de realizar esta experiencia de usuario tiene dos dimensiones: el de detectar problemas de usabilidad en la aplicación de Aprendizaje-Servicio que se está desarrollando y el de analizar la utilidad de la misma. Para la consecución de este propósito, y al contar con un prototipo preliminar pero actualmente funcional que permite realizar tareas en profundidad, hemos estimado que la mejor manera de realizar esta evaluación con usuarios es a través de pruebas de evaluación junto a la realización posterior de un cuestionario y entrevista tipo TAM/UTAUT (Technology Acceptance Model [6] / Unified Theory of Acceptance And Use Of Technology [7]). Las pruebas de evaluación siguen unos objetivos generales que se adecuan considerablemente bien a los objetivos que se pretenden alcanzar en esta experiencia de usuario, y se enumeran a continuación: ● Verificar si el diseño general de la aplicación web es consistente y permite realizar a los diferentes tipos de usuario tareas complejas recogidas en un flujo de trabajo o una lista de tareas de forma autónoma. ● Obtener una lista con los puntos de la interfaz en los que los usuarios se quedan atascados, cometen errores o encuentran inconsistencias. ● Comprobar si el diseño cumple las expectativas del usuario y concuerda con su modelo mental de una posible aplicación aprendizaje-servicio. Para conseguir este último objetivo, se realizará el modelo de cuestionario TAM/UTAUT, que utiliza una serie de variables que recogen información como la siguiente: ● Analizar el grado en el que los usuarios piensan que utilizar la aplicación les ayudará a realizar lo que buscan de manera más efectiva y eficiente, a través de la utilidad percibida. ● Evaluar el grado en el que los usuarios esperan que la aplicación les ayude a optimizar sus esfuerzos a la hora de navegar por ella y la facilidad de interacción con su interfaz, a través de la facilidad de uso de la aplicación percibida. ● Determinar el grado de satisfacción de los usuarios al utilizar la aplicación, a través de su actitud frente al uso de la misma, de su intención a utilizarla en un futuro y de si la recomendaría a otros usuarios diferentes. 7.3. Preguntas de investigación Para refinar los objetivos propuestos en el epígrafe anterior, en concreto, los objetivos que se esperan cumplir a partir de la información obtenida en los cuestionarios y de la verificación de la contundencia del diseño general de la página web de las tareas del flujo de trabajo, es necesario realizar la formulación de las preguntas de investigación, que representan las cuestiones que se esperan que el usuario conteste después de haber interactuado con la aplicación. 55 Debido a la naturaleza específica, precisa y medible que deben seguir las preguntas de investigación, y que lo que pretendemos evaluar es una aplicación web de soporte al aprendizaje-servicio, consideramos apropiadas para la investigación las siguientes preguntas: ● ¿Cumple la aplicación el modelo mental de los usuarios? ● ¿Son los usuarios capaces de terminar las tareas del flujo de trabajo en un tiempo aceptable? ● ¿Es útil la aplicación para los usuarios? ● ¿Es la aplicación fácil de utilizar? ● ¿Consideran los usuarios que la aplicación es apropiada? ● ¿Están satisfechos los usuarios después de utilizar la aplicación? Estas preguntas, estarán presentes a la hora de elaborar el cuestionario que se realizará a los usuarios durante la sesión de evaluación, y quedarán resueltas durante la fase de la elaboración del informe de evaluación, en concreto, en la presentación de resultados de investigación. 7.4. Requisitos de los participantes La aplicación de aprendizaje-servicio que hemos ido desarrollando, en cooperación con otros alumnos en años anteriores, cuenta con una serie de roles diferentes con funciones muy diferentes entre sí. Los requisitos de cada rol se describen de forma detallada a continuación: ●Profesores: Son docentes de alguna universidad interesados en respaldar una demanda presentada por alguna entidad, o en presentar una oferta que pueda ser de interés para algún socio. Se encarga de gestionar el proyecto de Aprendizaje-Servicio, y de aceptar alumnos que participen en este. ●Alumnos: Son estudiantes que desean participar en un proyecto de Aprendizaje-Servicio para realizarlo bajo la tutorización del profesor. De esta manera, el alumno puede buscar y solicitar acceso a alguno de todos los proyectos ApS disponibles en el que quiera participar. Además, pueden sugerir demandas a través de un formulario de contacto. ●Socios comunitarios: Son instituciones que pueden identificar una necesidad social en el seno de su organización y presentar una demanda de servicio, que puede ser respalda por un profesor. ●Administradores: Son usuarios encargados de administrar el contenido de la aplicación. ●Oficina ApS: Son gestores que se encargan de gestionar los proyectos de Aprendizaje-Servicio que existen en la aplicación. Además, tanto los profesores como los alumnos pueden ser tanto internos como externos. Los internos representan usuarios de la universidad en la que se aloja la aplicación, mientras que los externos representan usuarios que no forman parte de esa universidad en cuestión. Esta diferencia, a efectos de la interacción con la aplicación, es especialmente importante en los profesores, ya que solo los internos pueden crear ofertas de servicio y ser responsables del partenariado y del proyecto, mientras que los externos solo pueden participar evaluando y guiando a estudiantes externos. 56 Cabe destacar también que, durante la discusión de los requisitos de la evaluación entre los alumnos y los directores, se consideró apropiado incluir un rol adicional de cara a los posibles usuarios que podían participar en la experiencia de usuario, al que nos referiremos a partir de ahora como “Expertos ApS”, que representan a los profesores con conocimientos del aprendizaje-servicio, y que por lo tanto, conocen cómo funcionan este tipo de servicios tanto desde la perspectiva del profesor como del socio comunitario. Finalmente, se decidió realizar la experiencia de usuario solo a profesores internos y a socios comunitarios, ya que la lógica de la aplicación implementada hasta el momento solo soportaba la interacción de este tipo de roles. Además, se decidió prescindir del rol de “Experto ApS”, ya que el moderador se encargaría de realizar la parte complementaria al usuario que esté realizando la experiencia. 7.5. Diseño experimental El diseño experimental describe el contexto de la evaluación y el estudio que se va a realizar sobre los datos. En concreto, durante el diseño experimental, se definen los siguientes artefactos, que se desarrollarán en secciones posteriores: ● Flujos de trabajo para los usuarios ● Descripción del entorno y de las herramientas que se van a utilizar ● Tareas del moderador ● Datos que se van a recolectar y metodología de análisis de datos. 7.5.1. Flujos de trabajo de los usuarios Al tratarse de una aplicación que soporta varios roles diferentes, con funcionalidades complementarias entre sí, es necesario definir un flujo de trabajo diferente para cada tipo de usuario, definidos en la sección anterior. La lista de tareas de cada usuario vendrá determinada por su flujo de interacción de los diagramas del modelo que se desarrollaron durante el curso anterior. Por otra parte, las tareas que realizarán los usuarios se describirán acorde al modelo de tareas escenario, ya que presentan las tareas de forma muy cercana a cómo se las podrían encontrar en la vida real, a diferencia de las tareas directas, que al ser tan técnicas y específicas, pueden perjudicar la experiencia de usuario. Las tareas escenario ayudarán a que el usuario no sienta que está siendo evaluado, pero el moderador deberá tener cuidado de que el usuario no se despiste de los objetivos generales de la evaluación. Además, para definir los flujos de trabajo, la aplicación deberá contar con unos casos de prueba prefabricados de manera que el usuario pueda trabajar e interactuar con todas las situaciones posibles que le permita la perspectiva de su rol, ya que no es posible en una simulación de estas características que el usuario interactúe con otros usuarios, que no sea el moderador, en tiempo real. Para esto, se poblará la base de datos con ofertas y demandas, tomando como ejemplos algunas experiencias ApS ya implementadas como las siguientes: ●https://www.aprendizajeservicio.net/ ●https://aprendizajeservicio.upm.es/aps-en-la-upm/proyectos/ 57 2. Instrucciones para la sesión de interacción Una vez el usuario responda a las preguntas, el moderador procederá a entregarle el flujo de trabajo correspondiente al participante y le explicará las normas ya mencionadas anteriormente en las tareas del moderador para el correcto desarrollo de la sesión de interacción con la aplicación. El moderador tendrá que ir realizando las tareas de la interacción del perfil complementario al usuario en los casos en los que sea necesario. 3. Instrucciones para el debriefing: cuestionario y entrevista. Después de que el usuario acabe con todos las tareas de la interacción, el moderador procederá a explicarle al usuario que, para cerrar la sesión de evaluación, será necesario realizar un debriefing. En primer lugar, el usuario realizará un cuestionario, en el que podrá hacer apreciaciones en voz alta si también lo desea. Puedes consultar el modelo de cuestionario en el apéndice 2 de este trabajo. Por último, el moderador le realizará una breve entrevista al usuario, con las siguientes preguntas: ● ¿Qué opinas sobre los datos que se piden en los formularios de registro? ¿Y en el formulario de oferta (profesores) / demanda (socio comunitario)? ¿Y del formulario de partenariado? ● ¿Qué funcionalidades te han resultado más intuitivas de utilizar? ● ¿Qué funcionalidades te han resultado más confusas de utilizar? ● ¿Crees que la aplicación funciona correctamente o ha funcionado mal en alguna ocasión cuando estabas interactuando con ella? ● ¿Tienes alguna cuestión u observación adicional que quieras añadir en relación a la aplicación? Finalmente, el moderador despedirá al usuario y parará de grabar la sesión. Esto supondrá el fin de la sesión de interacción. 7.8.2. Guión para el usuario 1. Flujo de trabajo para el profesor interno Un día de trabajo cualquiera, de camino a tu despacho, te cruzas en el pasillo a un compañero que te comenta que el departamento de Servicios Informáticos de la universidad ha impulsado recientemente una aplicación web de soporte al Aprendizaje-Servicio de la que todo el mundo lleva hablando desde hace varios días. Casualmente, llevabas un tiempo esperando tener acceso a una app de esas características, así que una vez llegas a tu escritorio y enciendes el ordenador, te metes directamente en la página web en cuestión: https://soporteaps.intecca.uned.es. 64 Una vez dentro, navegando en la página principal, encuentras una sección en la que se encuentran los tres tipos de perfiles que se contemplan en la aplicación, y accedes al de profesor para tener más información. Si te quedas con dudas o te ves un poco perdid@, decides seguir leyendo sobre cómo funciona la aplicación en la página que explica lo que es ApS alojada en la aplicación. Después de terminar de leer, decides crearte una cuenta para comenzar a involucrarte con la aplicación. Estando dentro de la página de registro, llenas el formulario con tus datos y lo envías para finalizar el registro. Sin embargo, justo después recibes un correo electrónico de sistemas informáticos, lamentándose de que por ahora, debes utilizar la cuenta de profesor interno que tiene creada la universidad. Por ello, cierras sesión y te logeas, en el apartado de LOGIN UNED, con las credenciales que aparecen en el correo, (email profesorI[email protected] y contraseña profesorInterno1). Una vez logead@, observas como en el menú de navegación aparecen nuevas opciones. En primer lugar, decides observar las ofertas que se encuentran actualmente en la web, para hacerte una idea del formato de estas. Una vez estás dentro del listado, haces click en la oferta que más te llama la atención, y observas todos sus detalles. Cuando terminas de leer, decides crear tú también tu primera oferta, así que procedes a ello, buscando la opción que te permite crear una oferta en algún lugar de la página web. Una vez la encuentras, procedes a rellenar el formulario con la información necesaria. Cuando terminas, envías el formulario y compruebas que tu oferta se ha creado correctamente en tu lista de ofertas personal. Mientras que esperas a ver si algún socio comunitario está interesado en tu oferta, decides explorar las demandas para ver si encuentras alguna que te llama la atención. Para ello, te diriges a lista de demandas de servicio, y a continuación, comienzas a probar filtros para ajustar más tu búsqueda con tus preferencias personales. Si con esos filtros no aparece ninguna demanda, no desesperas y pruebas otros filtros diferentes con el fin de encontrar alguna demanda que te interese. Una vez la encuentras, decides crear un partenariado y rellenas el formulario con la información necesaria. Cuando lo envías, compruebas que el partenariado se ha creado en tu lista de partenariados. Después de esto, compruebas si ya has recibido una notificación avisándote de que tu oferta ha sido aceptada por algún socio, mirando en el historial de notificaciones y buscando la notificación adecuada. Antes de decidir si aceptas o no al socio, compruebas sus datos personales accediendo a su perfil. Como te genera confianza, finalmente decides aceptar, y rellenas los datos del formulario para crear el partenariado. Después de unos minutos, vuelves a comprobar el historial de notificaciones para observar si has recibido la notificación de que el socio ha terminado de crear el partenariado. Por último, te diriges a tu lista de partenariados y compruebas que se han creado. ¡Genial! Después de esto, decides tomarte un respiro. Cierras la sesión y decides irte a tomar un café con tus compañeros para comentar tu primera experiencia en la aplicación. 65 2. Flujo de trabajo para el socio comunitario Navegando por Internet en busca de una página web de Aprendizaje-Servicio, encuentras una publicación de los servicios informáticos de la UNED en donde explican que han lanzado una aplicación que cubre precisamente esa funcionalidad. Decides echarla una vistazo, tecleando la dirección https://soporteaps.intecca.uned.es. Una vez dentro, navegando en la página principal, encuentras una sección en la que se encuentran los tres tipos de perfiles que se contemplan en la aplicación, y accedes al de socio comunitario para tener más información. Si te quedas con dudas o te ves un poco perdid@, decides seguir leyendo sobre cómo funciona la aplicación en la página que explica lo que es ApS alojada en la aplicación. Después de terminar de leer, decides crearte una cuenta para comenzar a involucrarte con la aplicación. Estando dentro de la página de registro, llenas el formulario con tus datos y lo envías para finalizar el registro. Una vez estás registrad@, observas como en el menú de navegación aparecen nuevas opciones. Decides observar las ofertas que se encuentran actualmente en la web para ver si encuentras alguna que te interesa. Para tener una búsqueda más precisa, decides utilizar los filtros de manera que los resultados que te aparezcan se acerquen más a tus preferencias. Si con esos filtros no aparece ninguna oferta, no desesperas y pruebas otros filtros diferentes con el fin de encontrar alguna oferta que te interese. Una vez la encuentras, decides aceptar la oferta. Mientras el profesor decide aceptarte como socio, decides crear tu propia demanda. Para ello, rellenas el formulario necesario con la información apropiada. Una vez envías el formulario, compruebas que se ha creado correctamente. A continuación, compruebas en tu lista de notificaciones que el profesor te ha aceptado, por lo que procedes a completar el partenariado con los datos que procedan. Una vez terminado, y al mirar de nuevo en la lista de notificaciones, te das cuenta que un profesor ha aceptado la demanda que habías creado hace unos minutos, por lo que vuelves a rellenar el formulario para terminar el partenariado de la misma manera que antes. Por último, vas a tu lista de partenariados para comprobar que se han guardado correctamente y les echas un vistazo. ¡Genial! Después de esto, decides tomarte un respiro. Cierras la sesión y decides irte a tomar un café con tus compañeros para comentar tu primera experiencia en la aplicación. 66 7.9. Análisis de datos Durante las sesiones de evaluación, el moderador disponía de una plantilla en la que recogía, para cada tarea que el usuario realizaba, su estado (si la completó sin errores o con errores o si no la completó), el tiempo aproximado que le llevaba realizarla (en caso de que la completara) y comentarios adicionales sobre las sensaciones del profesor o del socio mientras interactuaba con cada funcionalidad. Una vez terminaba la interacción, el usuario rellenaba el cuestionario mientras que el moderador calculaba las métricas para el usuario, estas son el número y la tasa de tareas completadas sin errores, con errores, no completadas y el tiempo total de interacción, y trasladaba los resultados de los tiempos por tarea a la tabla de resultados generales. Por último, durante la entrevista final, se recogían los comentarios más importantes no mencionados en la interacción para tenerlos en consideración a la hora de realizar el análisis. Todos estos datos serán analizados a lo largo de este epígrafe, con el fin de cumplir los objetivos propuestos durante la planificación de la experiencia de usuario. El análisis de cada tipo de datos cubrirá una parcela de información, de la que se podrán extraer unas conclusiones que se recogerán posteriormente en los informes de resultados y hallazgos y recomendaciones. A continuación, en la siguiente tabla, se muestran los objetivos de evaluación que se pretenden cumplir y el informe correspondiente en el que se comentarán los resultados obtenidos para cada tipo de datos que se va a analizar. Datos que se van a analizar Objetivo que se pretende cumplir con el análisis Informe correspondiente Métricas de interacción Verificar si el diseño general de la aplicación web es consistente y permite realizar a los diferentes tipos de usuario tareas complejas recogidas en un flujo de trabajo o una lista de tareas de forma autónoma. Resultados de investigación Comentarios realizados durante la sesión de interacción y la entrevista Obtener una lista con los puntos de la interfaz en los que los usuarios se quedan atascados, cometen errores o encuentran inconsistencias. Informe de hallazgos y recomendaciones Cuestionario Comprobar si el diseño cumple las expectativas del usuario y concuerda con su modelo mental de una posible aplicación aprendizaje-servicio. Resultados de investigación 67 7.9.1. Análisis de las métricas de la interacción Para recoger la información necesaria que permitiera poder realizar un análisis de métricas, se elaboraron dos plantillas de usuario diferentes, una para utilizar en sesiones con profesores, y otra para sesiones en las que participaba un socio comunitario. Para elaborarla, en primer lugar fue necesario romper las tareas escenario del flujo de trabajo en tareas directas, ya que a pesar de que es beneficioso para los usuarios presentar un flujo de trabajo de manera que los pasos a seguir se describan de manera que simulen una situación real, para el análisis es preferible tener una lista de instrucciones literales para poder diferenciarlas. De esta manera, se identificaron 17 tareas para el rol de profesor, mientras que para el socio comunitario se obtuvieron 12, que se recogen en los listados que aparecen a continuación: Profesor 1. Búsqueda de información 2. Registro 3. Login 4. Encontrar listado de ofertas 5. Explorar listado de ofertas 6. Encontrar botón de crear oferta 7. Rellenar formulario de oferta 8. Encontrar listado de ofertas personal 9. Encontrar listado de demandas 10. Explorar listado de demandas con filtros 11. Rellenar formulario de partenariado (respalda de demanda) 12. Búsqueda de lista de notificaciones 13. Explorar lista de notificaciones (búsqueda de notificación de oferta aceptada) 14. Comprobar datos del socio 15. Rellenar formulario de partenariado (completar datos de oferta) 16. Explorar lista de notificaciones (búsqueda de notificación de partenariado creado) 17. Encontrar listado de partenariados personal Socio comunitario 1. Búsqueda de información 2. Registro 3. Encontrar listado de ofertas 4. Explorar listado de ofertas con filtros 5. Encontrar opción de crear demanda 6. Rellenar formulario de demanda 7. Búsqueda de lista de notificaciones 8. Explorar lista de notificaciones (búsqueda de notificación petición aceptada) 9. Rellenar formulario de partenariado (petición aceptada) 10. Explorar lista de notificaciones (búsqueda de notificación demanda respaldada) 11. Rellenar formulario de partenariado (demanda respaldada) 12. Encontrar listado de partenariados personal 68 Una vez identificadas las tareas, se procedió a construir las plantillas. El contenido de estas constaba de una rúbrica en la que para cada tarea definida en el flujo de trabajo, se recogía la siguiente información: ● El estado de la tarea, que podía tomar los siguientes valores: ○ Completada sin errores, es decir, el usuario completa la tarea tal y como se esperaba cuando se definió. ○ Completada con errores, es decir, el usuario completa la tarea pero comete fallos a la hora de interactuar con la aplicación o la completa de una manera que no se contemplaba cuando se definió. ○ No completada, es decir, el usuario no termina la tarea, bien porque la omite o bien porque no sabe cómo realizarla. ● El tiempo que tardaba en realizar la tarea, aproximado al múltiplo de 5 segundos más cercano, siempre y cuando la tarea quedara completada. ● Los comentarios que el usuario realizaba en relación a la tarea, o su comportamiento cuando se tenía que enfrentar a esa funcionalidad. Además de la rúbrica, se encontraba una tabla con las métricas generales para ese usuario, en la que se calculaba la tasa de tareas completadas sin errores, la tasa de tareas completadas con errores, la tasa de tareas no completadas y el tiempo total empleado para completar todas las tareas y un cuadro de comentarios generales que se recogían durante la entrevista, que servían para bien reforzar una idea que el usuario realizó durante la interacción, o para aportar sugerencias nuevas que no se habían mencionado antes. No obstante, estas métricas a nivel de usuario por sí solas no aportaban información demasiado relevante para el conjunto del análisis. Aunque se pueden observar a modo de consulta en el apéndice 3 de este trabajo, realmente su utilidad viene cuando se ponen en conjunto con el resto de usuarios del mismo rol. Por ello, se crearon dos rúbricas adicionales, una para el rol de profesor y otra para el de socio comunitario, de manera que se pudieran obtener los resultados de las sesiones desde una perspectiva general. Estas rúbricas contienen, para cada tarea, el tiempo que tarda cada usuario en realizarla (7 usuarios en caso de los profesores y 2 usuarios en caso de los socios comunitarios), coloreados siguiendo los siguientes criterios: ● De color verde si el usuario completaba la tarea sin errores. ● De color naranja si el usuario completaba la tarea con errores. ● De color rojo si el usuario no completaba la tarea. A partir de esta información, se calculaban, ahora sí, las métricas globales de interacción por tarea, que son las siguientes: ● Tasa de usuarios que han completado la tarea sin errores (%U.S.). ● Tasa de usuarios que han completado la tarea con errores (%U.C.). ● Tiempo medio global en el que se completa la tarea (t.). ● Tasa de usuarios que no han completado la tarea (%U.N.). ● Tasas globales y tiempo medio global de interacción. A continuación, se muestran los resultados obtenidos en primer lugar para los profesores y después para los socios comunitarios, recogidos en las siguientes páginas. 69 Tarea Profesores Métricas 1 2 3 4 5 6 7 %U.S. %U.C. t. %U.N. 1 7m 15s x 2m 20s 1m 50s 4m 15s 7m 7m 30s 71% 14% 5m 5s 14% 2 6m 50s x 2m 40s 11m 30s 3m 20s 5m 10s 2m 29% 57% 5m 15s 14% 3 30s 5s 30s 30s 10s 5s 30s 100% 0% 20s 0% 4 5s 2m 5s 5s 5s 5s 5s 86% 14% 20s 0% 5 2m 30s 2m 30s 1m 15s 50s 2m 2m 50s 2m 71% 29% 2m 0% 6 5s 5s 5s 20s 5s 5s 5s 100% 0% 5s 0% 7 9m 20s 8m 3m 4m 10s 4m 10s 3m 25s 2m 30s 29% 71% 4m 55s 0% 8 x x 5s x 5s x x 29% 0% 5s 71% 9 5s 5s 5s 5s 5s 5s 5s 100% 0% 5s 0% 10 4m 30s 7m 3m 2m 50s 2m 2m 1m 30s 86% 14% 3m 15s 0% 11 7m 20s 5m 45s 1m 55s 5m 30s 2m 10s 2m 25s 2m 30s 14% 86% 3m 55s 0% 12 30s 5s 5s x 5s 5s 5s 57% 29% 10s 14% 13 1m 45s 1m 30s 1m 35s 30s 5s 2m 20s 15s 29% 71% 1m 10s 0% 14 x x 20s x 5s 5s 10s 57% 0% 10s 43% 15 x 2m 10s 1m 30s 2m 20s 5s 30s 43% 43% 1m 5s 14% 16 x 1m 30s 30s x 5s 5s 5s 57% 14% 25s 29% 17 x x 5s 10s 5s 5s 5s 71% 0% 5s 29% Glob. 40m 45s 30m 45s 19m 15s 20m 20s 19m 10s 25m 55s 28m 25s 61% 26% 28m 25s 13% En primer lugar, con respecto a las tasas obtenidas para los profesores, observamos una alta tasa de tareas completadas sin errores, alcanzando el 61%. Sin embargo, observamos un 13% de tareas sin completar y un 26% de tareas completadas con errores, por lo que a priori, se requiere un análisis más profundo para indagar en los motivos. 70 Si comenzamos por la tasa de tareas completadas sin errores, observamos que el 100% de profesores completa con éxito las tareas de login, de encontrar el botón de crear oferta y el de encontrar el listado de demandas.Esto tiene bastante sentido, ya que como se comprobará posteriormente en el análisis de los comentarios, no se recogió ningún comentario negativo por parte de ningún profesor con respecto a estas tareas. Por lo tanto, se puede concluir que estas tareas resultan bastante intuitivas para los usuarios y no hay ningún problema que mencionar al respecto. Si continuamos observando las tareas con altas tasas de profesores que la completan sin errores, encontramos las siguientes tareas, ordenadas de mayor a menor tasa: % U.S. Tarea Explicación a los errores de los usuarios 86% Encontrar listado de ofertas La única persona que no es capaz de encontrar el listado sin problemas es porque durante la sesión de evaluación, no veía apropiadamente la pantalla del ordenador. Explorar listado de demandas con filtros Una persona intenta seleccionar varias necesidades sociales a la vez en el filtro y no entiende que la implementación actual no lo permite, aunque en la lista desplegable se puedan seleccionar a priori más de uno. 71% Búsqueda de información Dos personas parecen bastante perdidas al interactuar por primera vez con la aplicación. Explorar listado de ofertas Dos personas no son capaces de encontrar el listado de ofertas en la barra de navegación, y lo encuentran en una de las secciones de la página principal. Encontrar listado de partenariados personal Dos personas no son capaces de encontrar el listado porque no interactúan con el área personal. 57% Búsqueda de lista de notificaciones Una parte considerable de los usuarios ignora la campana de notificación porque no se muestra el número de notificaciones actualizado en el icono, encuentran el listado en el Resumen del área personal. Comprobar datos del socio Una parte considerable de los usuarios se salta este paso al leer el flujo de trabajo. Las personas que leen y siguen el flujo de trabajo no tienen ningún problema para encontrar el enlace. Explorar lista de notificaciones (búsqueda de notificación de partenariado creado) Algunos usuarios rellenan el formulario correspondiente con errores, por lo que el partenariado no se crea y por lo tanto no pueden encontrar esa notificación. 71 De las tareas mencionadas anteriormente, solo dos son preocupantes, como se analizará en el informe de hallazgos y recomendaciones, ya que suponen errores de implementación graves. Estos problemas son el no mostrar el número de notificaciones en la campana automáticamente y el poder enviar formularios con errores en los datos que se recogen. Sorprendentemente, hay un empate entre los profesores que completan con errores y sin errores la tarea de rellenar el formulario de partenariado que completa los datos de la oferta. Como analizaremos después, esto se debe a que mientras que para algunos profesores les resulta bastante intuitiva la distribución del formulario y entienden lo que tienen que hacer, otros se pierden porque no saben qué es lo que tienen que rellenar exactamente dado que todos los campos aparecen como modificables. Con respecto a las tareas con altas tasas de profesores que la completan con errores, podemos observar lo siguiente: % U.C. Tarea Explicación a los errores de los usuarios 86% Rellenar formulario de partenariado (petición aceptada) La mayoría de usuarios comete errores al rellenar y enviar los formularios porque algunos campos son confusos y no se valida si los datos que se introducen son correctos o no. 71% Rellenar formulario de oferta Explorar la lista de notificaciones (búsqueda de notificación de oferta aceptada) La manera en la que la lista de notificaciones está distribuida confunde a muchos usuarios, ya que no hay un orden cronológico, no se distinguen las notificaciones leídas de las no leídas y no hay información adicional a cada notificación. 57% Registro Los errores que se muestran en el campo de la contraseña son poco explicativos, lo que lleva a los usuarios a emplear demasiado tiempo en pensar una contraseña correcta. Todos estos errores son considerablemente graves, ya que son fallos de implementación que provocan que los usuarios no interactúen correctamente o como se espera con la aplicación. Estos problemas también se tratarán en el informe de hallazgos y recomendaciones. Por último, la única tarea con una alta tasa de profesores que no la completan es la de buscar el listado de ofertas personal, ya que muchos creen que ese listado es el listado de ofertas general, y no exploran el área personal para encontrarla. No es un fallo significativo ya que se debe a un error de interpretación de los profesores al leer el flujo de trabajo. 72 Una vez analizadas las tasas, a continuación procedemos a analizar las métricas relacionadas con el tiempo que tardan los usuarios en completar las tareas. En primer lugar, si calculamos el porcentaje de tiempo que se dedica a cada tarea sobre el tiempo medio total (es decir, el tiempo medio en el que se termina el flujo de trabajo completo), obtenemos los siguientes resultados: Una de las tareas que abarca más porcentaje de tiempo empleado es la búsqueda de información, aunque de cara al estudio no es muy relevante, ya que la mayor parte del tiempo que se dedica en esta tarea es a leer la información de cómo funciona la página web. Sin contar la búsqueda de información, las tareas que abarcan más del 10% del tiempo total son rellenar el formulario de registro (con un 18,48%), rellenar el formulario de oferta (con un 17,30%) y rellenar el formulario de partenariado (con un 13,78%). Curiosamente, estas tareas son precisamente las que pertenecen a las funcionalidades con mayor número de comentarios recibidos, como se comprobará después en el análisis de comentarios, y también, son las tareas con las tasas de usuarios más altas que la completan con errores, lo que ya viene indicando que en futuras implementaciones, habrá que mejorar la presentación de los formularios. Por otra parte, de las tareas que apenas llevan un 1,5% del tiempo total, podemos destacar las de login, encontrar el listado de ofertas, demandas, partenariados y notificaciones, encontrar el botón de crear oferta, comprobar los datos de los socios. Esto es bastante positivo, ya que esto se puede traducir en que los usuarios encuentran los controles de la página donde esperarían encontrarlos, por lo que la interfaz de la aplicación es intuitiva para ellos. Esto se confirmará posteriormente en el análisis del cuestionario. 73 Encontrar listado de ofertas No hay comentarios. Encontrar listado de demandas (profesores) No hay comentarios. Explorar listado de ofertas (con o sin filtros) ● Corregir los controles de navegación del listado de ofertas (página anterior y siguiente, contador de ofertas…) (3). ● Cambiar el icono del ojo por un enlace en el título de la oferta para visualizarlo porque es más intuitivo (2). ● Controlar que las ofertas que superan la fecha límite deben desaparecer (1). ● Indicar la apropiabilidad de la oferta para el alumnado según la titulación que estén estudiando (1). ● Ordenar las ofertas cronológicamente de más nuevas a más antiguas (1). ● Añadir un campo para explicar la función de cada rol (1). Explorar listado de demandas con filtros (profesores) ● Cambiar el filtro de necesidad social para que permita elegir varias (2). ● Añadir más titulaciones, ya que faltan bastantes (1). ● Añadir información adicional sobre cada campo al visualizar la demanda (1). ● Corregir los controles de navegación del listado de demandas (página anterior y siguiente, contador de demandas…) (1). Rellenar formulario de oferta (profesores) ● Cambiar el campo de año académico objetivo por curso académico objetivo (5). ●Devolver a la página del listado de ofertas una vez envías el formulario (3). ● Añadir un campo adicional con un enlace externo para aportar información adicional de la oferta (2). ● Añadir ayuda adicional para cada campo (2). ● El área de implementación debería permitir tanto elegir de la lista como escribir el que uno quiera (2). ● Quitar la explicación entre paréntesis del campo tag porque confunde (2). ● Controlar que la oferta no se cree cuando al enviar un formulario recibes un error (1). ● Aportar información de error adicional cuando se envía un formulario incorrecto (1). ● Controlar que los campos reciben la información que se espera y mostrar un error en caso contrario (1). ● Cambiar el nombre del campo tag por keyword porque es más intuitivo (1). Rellenar formulario de demanda (socios) ● Implementar el formulario de manera que los campos de información relacionados con las fechas sean más genéricos en vez de tan estrictos (2). ● Implementar el campo de necesidad social de manera que se pueda elegir de una lista desplegable o elegir el que quieras (1). 80 Rellenar formulario de partenariado ● Añadir ayuda adicional para cada campo (5). ● Cambiar el campo de año académico objetivo por curso académico objetivo (5). ● Los campos de demanda o de información general no deberían ser editables cuando un profesor o los de oferta cuando un socio está rellenando el formulario de partenariado (4). ● Mejorar la distribución del formulario de manera que los campos que no se deben modificar aparezcan al principio para saber qué campos son los que hay que editar (3). ● Corregir la implementación para que en el formulario de partenariado de aceptación del socio no haya que volver a rellenar datos de oferta que se habían introducido antes (2). ● No mostrar una advertencia desde que abres el formulario porque confunde al usuario de que está haciendo algo mal (1). ● Mostrar los campos obligatorios (1). ● No mostrar una advertencia al final de la página con todos los errores y mostrar el error a nivel de campo (1). Buscar la lista de notificaciones ● Corregir la implementación actual para que el número de notificaciones se muestre automáticamente en la campana sin tener que darle click antes (7). ● Crear un apartado en el área personal que se llame Mis Notificaciones (1). Explorar lista de notificaciones ● Mejorar la navegabilidad de la lista de notificaciones para que aparezca la información más clara, las marcas temporales, si está leída o no, información detallada relacionada con la notificación para saber cuál es cuál, etc. y esté ordenada cronológicamente (5). Comprobar datos del socio o profesor No hay comentarios. Encontrar listado de ofertas personal (profesores) No hay comentarios. Encontrar listado de demandas personal (socios) No hay comentarios. Encontrar y explorar listado de partenariados personal ● La información contenida en los partenariados no es correcta, por ejemplo el área de conocimientos del partenariado (4). ● No se debería poder cambiar el nombre del partenariado y debería salir igual que el nombre de la oferta y la demanda (2). ● El estado del partenariado no debería salir en el título (2). ● Corregir los controles de navegación del listado de partenariados (página anterior y siguiente, contador de partenariados…) (1). 81 A continuación, para analizar los comentarios recibidos, recogeremos dos variables por cada funcionalidad, el número de comentarios diferentes (esto es, comentarios únicos) y el número de comentarios totales (es decir, contemplando comentarios repetidos por varios usuarios). En primer lugar, realizaremos un examen sobre el número de comentarios únicos, de manera que podamos observar cuáles han sido las funcionalidades que han recibido más comentarios en proporción al total y cuáles han sido las que no han recibido ningún comentario, e intentar encontrar relaciones con las métricas obtenidas durante la sesión de interacción. Una vez hecho el análisis de comentarios únicos, procederemos a estudiar el número de comentarios total, determinando cuáles son las funcionalidades que experimentan mayor variación con respecto al número de comentarios diferentes y cuáles menos, encontrando en cualquier caso una explicación que lo justifique. Funcionalidad Número de comentarios diferentes Número de comentarios totales Buscar información y navegación general 11 17 Rellenar formulario de registro 9 20 Login 0 0 Encontrar listado de ofertas 0 0 Encontrar listado de demandas (profesores) 0 0 Explorar listado de ofertas (con o sin filtros) 6 9 Explorar listado de demandas con filtros (profesores) 4 5 Rellenar formulario de oferta (profesores) 10 20 Rellenar formulario de demanda (socios) 2 3 Rellenar formulario de partenariado 8 22 Buscar la lista de notificaciones 2 8 Explorar lista de notificaciones 1 5 Comprobar datos del socio o profesor 0 0 Encontrar listado de ofertas personal (profesores) 0 0 Encontrar listado de demandas personal (socios) 0 0 Encontrar y explorar listado de partenariados personal 4 9 82 83 Podemos observar, en primer lugar, que las funcionalidades con más comentarios diferentes recibidos son en primer lugar la búsqueda de información y navegación general, con 11, a continuación el relleno de formulario de oferta con 10 y en tercer lugar el relleno del formulario de registro con 9 y de partenariado con 8. Esto supone que solo un cuarto de las tareas (4 de 16) representen el 67% del total en cuanto a comentarios únicos recibidos, o dicho de otra manera, dos terceras partes de la totalidad. Casualmente, si observamos las métricas de interacción, las tareas relacionadas con esas funcionalidades son en las que más tiempo medio invertían los usuarios cuando interactuaban con la aplicación, por lo que tiene bastante sentido que el número de comentarios únicos sea más alto en comparación al del resto. Por otra parte, tanto el login, como encontrar los listados de oferta y demanda generales y personales, y comprobar los datos del socio o del profesor, no reciben ningún comentario por parte de ningún usuario. Este hecho guarda bastante correlación con las métricas obtenidas en el epígrafe anterior, ya que estas tareas en particular tienen una tasa nula de haber sido completada con errores, lo que viene a significar que, o bien se completan sin errores o bien que no se completan porque son ignoradas desarrollando el flujo de trabajo, por lo que es normal que no se hayan recibido comentarios al respecto. Sin embargo, si observamos el número de comentarios totales, se producen algunas alteraciones en el ránking. No obstante, al valorar esta variable en términos absolutos, se pierde información bastante llamativa. Por ello, valoraremos la variación que se produce con respecto al número de comentarios diferentes, de manera que nos permita observar qué funcionalidades son en las que más comentarios se repiten, a través de la tasa de variación porcentual. En concreto, las tasas de variación del número de comentarios totales con respecto al número de comentarios diferentes por funcionalidad, omitiendo las que no recibieron ningún comentario, son las siguientes: Funcionalidad Tasa de variación Buscar información y navegación general 54,5% Rellenar formulario de registro 122% Explorar listado de ofertas (con o sin filtros) 50% Explorar listado de demandas con filtros (profesores) 25% Rellenar formulario de oferta (profesores) 100% Rellenar formulario de demanda (socios) 50% Rellenar formulario de partenariado 175% Buscar la lista de notificaciones 300% Explorar lista de notificaciones 400% Encontrar y explorar listado de partenariados personal 125% 84 Llama poderosamente la atención cómo las funcionalidades relacionadas con la lista de notificaciones (tanto la búsqueda como la exploración) son las que más varían, experimentando una variación del 300% y del 400% respectivamente, teniendo en cuenta el número de comentarios únicos, estas funcionalidades fueron de las que menos recibieron, con 2 y 1 comentarios. Esto viene a indicar que prácticamente todos los usuarios encontraron el mismo problema a la hora de interactuar con la lista de notificaciones, lo cual habrá que tener muy en cuenta en futuras implementaciones. Por el contrario, la funcionalidad que más comentarios únicos recibió, es decir, buscar información y navegación general, es curiosamente la cuarta que menos varía si tenemos en cuenta el número de comentarios totales, lo que significa que la mayoría de usuarios puntualizó aspectos diferentes, y por lo tanto, más genéricos y personales. Una vez hecho el análisis de los comentarios por funcionalidad, ordenaremos y agruparemos los comentarios, de mayor a menor número de usuarios que han repetido dicho comentario, para diferenciar de cara al siguiente epígrafe errores más genéricos de los que son más apreciaciones a nivel de usuario particular. Para evitar repeticiones innecesarias, y en caso de que alguno de los comentarios guarde parecido directo con otro pero pertenezca a una tarea diferente, o pertenezcan a la misma tarea y sean bastante relacionables, el comentario se generalizará para todas las funcionalidades relacionadas, tomando siempre el mayor número de usuarios de todos los comentarios agrupables. Además, señalaremos con asterisco simple o doble asterisco los comentarios realizados por socios comunitarios para tareas específicas para este tipo de usuarios, debido a que como hemos mencionado anteriormente, solo 2 usuarios han participado como socio comunitario en la sesión de evaluación, por lo que hay que tener en cuenta que el número de usuarios potenciales que pueden realizar algún comentario sobre esas tareas es considerablemente menor al de las tareas generales o a las de profesor. Número de usuarios Comentarios 6 o más ● Corregir la implementación actual para que el número de notificaciones se muestre automáticamente en la campana sin tener que darle click antes. 5 ● Explicar qué son las áreas de conocimiento de la UNESCO. ● Indicar qué tipos de caracteres especiales permite la contraseña. ● Cambiar el campo de año académico objetivo por curso académico objetivo en el formulario de oferta o de partenariado. ● Añadir ayuda adicional para cada campo en los formularios. ● Mejorar la navegabilidad de la lista de notificaciones para que aparezca la información más clara, las marcas temporales, si está leída o no, información detallada relacionada con la notificación para saber cuál es cuál, etc. y esté ordenada cronológicamente. 4 ● Mejorar el campo Universidad de manera que aparezca la palabra Universidad delante de cada una y poner las siglas de la universidad. 85 ● Los campos de demanda o de información general no deberían ser editables cuando un profesor o los de oferta cuando un socio comunitario está rellenando el formulario de partenariado. ● La información contenida en los partenariados no es correcta, por ejemplo el área de conocimientos del partenariado. 3 ● Incluir botones de navegación para volver atrás en la página. ● Redactar con lenguaje inclusivo. ● Corregir los controles de navegación del listado de ofertas, demandas y partenariados (página anterior, página siguiente, contador…). ● Devolver al listado de ofertas una vez envías el formulario de oferta. ● Mejorar la distribución del formulario de manera que los campos que no se deben modificar aparezcan al principio para saber qué campos son los que hay que editar. 2 ● Tener cuidado con las faltas de ortografía. ● Arreglar la imagen rota de la foto de perfil de usuario porque da a entender al usuario que no se puede interactuar con esa zona y por lo tanto no puede acceder al área personal. ● Cambiar el icono del ojo por un enlace en el título de la oferta para visualizarlo porque es más intuitivo. ● Debería haber un campo para recoger información sobre el departamento al que pertenece un profesor en el formulario de registro, así como un campo de biografía para todos los usuarios. ● Indicar la apropiabilidad de la oferta para el alumnado según la titulación que estén estudiando, así como añadir un campo para explicar la función de cada rol en la oferta. ●El campo de área de implementación en el formulario de oferta debería permitir tanto elegir de la lista como escribir el que uno quiera. ● Cambiar el filtro de necesidad social en la lista de demandas para que permita elegir varias. ● Quitar la explicación entre paréntesis del campo tag porque confunde. ● Añadir un campo adicional con un enlace externo para aportar información adicional de la oferta en el formulario de oferta. ● Implementar el formulario de demanda de manera que los campos de información relacionados con las fechas sean más genéricos en vez de tan estrictos (**). ● Corregir la implementación para que en el formulario de partenariado de aceptación del socio no haya que volver a rellenar datos de oferta que se habían introducido antes. ● No se debería poder cambiar el nombre del partenariado y debería salir igual que el nombre de la oferta y la demanda y el estado del partenariado no debería salir en el título. 1 ● Ordenar la información de todas las listas desplegables de los formularios alfabéticamente. ● Deberían verse todas las preguntas desde el principio en el FAQ y que se pudieran ir desplegando. ● Debe haber un sitio en la página en donde se expliquen cómo se tratan los datos recogidos en la página. ● Incorporar enlaces al carrusel de la página principal ya que si no carece de utilidad. ● Añadir comentarios o descripciones de accesibilidad a los iconos y a las imágenes. 86 ● Cuidar el contraste del fondo de la página y el texto de la aplicación eligiendo colores de letra que se vean bien en el color del fondo para mejorar la accesibilidad. ● Las páginas de Quiénes somos y contacta deberían aparecer desagrupadas para encontrarlas más fácilmente. ● Recibir correo de confirmación al completar el registro. ● Debería aparecer el botón de visualizar contraseña cuando la estás escribiendo en el formulario de registro. ● Incluir como pistas para escribir una contraseña correcta la longitud mínima de la contraseña en el formulario de registro. ● Corregir la implementación de manera que la página principal se abra desde el principio de la página cuando se envía el formulario de registro. ● Controlar que las ofertas que superan la fecha límite deben desaparecer. ● Ordenar las ofertas cronológicamente de más nuevas a más antiguas. ● Añadir más titulaciones, ya que faltan bastantes. ● Añadir información adicional sobre cada campo al visualizar la demanda. ● Controlar que la oferta no se cree cuando al enviar un formulario de crear oferta recibes un error. ● Aportar información de error adicional cuando se envía un formulario incorrecto. ● Controlar que los campos reciben la información que se espera y mostrar un error en caso contrario. ● Cambiar el nombre del campo tag por keyword porque es más intuitivo. ● Implementar el campo de necesidad social de manera que se pueda elegir de una lista desplegable o elegir tú el que quieras en el formulario de demanda (*). ● No mostrar una advertencia desde que abres el formulario en el formulario de partenariado porque confunde al usuario de que está haciendo algo mal. ● Mostrar los campos obligatorios en el formulario de partenariado. ● No mostrar una advertencia al final de la página con todos los errores y mostrar el error a nivel de campo en el formulario de partenariado. ● Crear un apartado en el área personal que se llame Mis Notificaciones. (*) Comentario recibido por un socio comunitario en una tarea exclusiva para este tipo de usuarios. (**) Comentario recibido por dos socios comunitarios en una tarea exclusiva para este tipo de usuarios. 87 7.9.3. Análisis de los cuestionarios Por último, y con el objetivo de evaluar la utilidad percibida, la facilidad de uso percibida y el grado de satisfacción del usuario al haber interactuado con la aplicación, se realizará un análisis de los resultados obtenidos en los cuestionarios. Para cada pregunta, se obtendrán la media, la moda, la mediana y la desviación típica de toda la muestra, y de los profesores y socios comunitarios por separado. Los valores obtenidos, junto al gráfico de los resultados, serán comentados brevemente. Finalmente, y una vez analizadas todas las preguntas, se realizará un estudio global de las resultados obtenidos, obteniendo la media y desviación típica globales, así como la distribución de las preguntas por media umbral, de manera que nos permita obtener una percepción general de cómo se distribuyen las respuestas de los usuarios. General Profesor Socio En general, los usuarios encuentran útil la aplicación porque les ahorra tiempo y dinero, con dos terceras partes de la muestra completa respondiendo que están de acuerdo. Mientras que los socios responden de manera unánime, los profesores tienen parecidos diferentes, aunque la mayor parte de ellos responde que está de acuerdo. Cabe destacar que un profesor responde que no está nada de acuerdo con la afirmación. Media 3,44 3,29 4 Moda 4 4 4 Mediana 4 4 4 Desviación Típica 1,01 1,11 0 88 General Profesor Socio Los usuarios están mayoritariamente de acuerdo en que la aplicación es útil por la rapidez con la que pueden hacer las cosas, respondiendo un 44,4% que están de acuerdo y el 33,3% que están muy de acuerdo. Esta vez no existe unanimidad en la respuesta de los socios, y presentan una desviación mucho más acentuada que la de los profesores. Sin embargo, en general, la distribución de las respuestas es bastante uniforme. Media 4,11 4,14 4 Moda 4 4 No Mediana 4 4 4 Desviación Típica 0,78 0,69 1,41 General Profesor Socio Cuando los usuarios son preguntados por si la aplicación mantiene su privacidad, parece que las respuestas se dispersan bastante. Una tercera parte responde que no está de acuerdo, concentrándose el mayor número de respuestas en torno a este valor. Los socios tampoco responden de manera unánime, aunque sus respuestas están más concentradas que la de los profesores, lo cual tampoco es muy significativo teniendo en cuenta que el tamaño de las muestra de los socios es mucho más pequeño. Media 2,89 3 2,5 Moda 2 No No Mediana 3 3 2 Desviación Típica 1,27 1,41 0,71 89 General Profesor Socio Por último, si tuvieran que volver a utilizar la aplicación si lo necesitaran, se encuentra la concentración más masiva de respuestas en torno a un valor de todo el cuestionario, con todos los usuarios menos uno (el 88,9%) respondiendo estar muy de acuerdo, lo cual es bastante positivo. Sin embargo, uno de los profesores se vuelve a distanciar considerablemente de la percepción general del resto, respondiendo que no está de acuerdo en que usaría la herramienta en otra ocasión en caso de necesitarla. Media 4,67 4,57 5 Moda 5 5 5 Mediana 5 5 5 Desviación Típica 1 1,13 0 Si calculamos la media y la desviación típica de todas las respuestas, se observa que en general los usuarios están de acuerdo con las afirmaciones planteadas en el cuestionario, obteniendo una media de 4,13. La desviación obtenida no es muy elevada (1,08), por lo que por lo general, las respuestas se distribuyen entre los valores 3 (indiferencia), 4 (de acuerdo) y 5 (muy de acuerdo), resultado bastante positivo. Media global 4,13 Desviación típica global 1,08 Además, si analizamos cómo se distribuyen las preguntas con medias umbrales decrecientes en 0,5 puntos, podemos observar que el 31% obtiene una media mayor de 4,5 (medio camino entre de acuerdo y muy de acuerdo) mientras que el 38% del total y el 88% acumulado obtiene una media superior a 3,5 (medio camino entre indiferente y de acuerdo). Media umbral ni fi Fi mayor que 5 0 0% 0% mayor que 4,5 5 31% 31% mayor que 4 8 19% 50% mayor que 3,5 14 38% 88% mayor que 3 15 6% 94% mayor que 2,5 16 6% 100% 96 7.10. Informe de hallazgos y recomendaciones Para elaborar el informe, se elaborará una lista a partir de los comentarios recibidos por los diferentes usuarios durante las sesiones de evaluación, agrupados en el epígrafe anterior, y reformulándolos de manera que permita identificar los problemas percibidos por los usuarios que existen actualmente en la aplicación, cumpliendo así con uno de los objetivos principales de esta experiencia de usuario. A continuación, calcularemos la prioridad (P) de un problema para ser solucionado en futuras implementaciones a través del producto de dos variables: ● La relevancia (R) del problema, que se obtiene a partir de aplicar los siguientes criterios: ○ Los comentarios repetidos por 1 o 2 usuarios tendrán un nivel de relevancia 1. ○ Los comentarios repetidos por 3 o 4 usuarios o los comentarios recibidos por un socio comunitario en una tarea específica para este tipo de usuarios tendrán un nivel de relevancia 2. ○ Los comentarios repetidos por 5 o 6 o más usuarios o los comentarios recibidos por dos socios comunitarios en una tarea específica para este tipo de usuarios tendrán un nivel de relevancia 3. ● La gravedad (G) del problema, que se asignará a partir de observar el comportamiento de los usuarios en las sesiones de evaluación y atendiendo a los siguientes criterios: ○ Los problemas que no provocan errores en la manera en la que los usuarios interactúan con la aplicación tendrán un nivel de gravedad 1. ○ Los problemas que provocan errores leves en la manera en la que los usuarios interactúan con la aplicación o que se tratan de errores de implementación triviales tendrán un nivel de gravedad 2. ○ Los problemas que provocan errores graves en la manera en la que los usuarios interactúan con la aplicación, problemas de accesibilidad o que se tratan de errores de implementación trascendentales tendrán un nivel de gravedad 3. Después de realizar el producto de relevancia y gravedad, se pueden obtener hasta 6 resultados diferentes, que se agruparán siguiendo los siguientes criterios: ● Los problemas con prioridad 1 y 2 serán problemas de prioridad baja. ● Los problemas con prioridad 3 y 4 serán problemas de prioridad media. ● Los problemas con prioridad 6 y 9 serán problemas de prioridad alta. A continuación, en la siguiente tabla, se recogen los 50 problemas encontrados a través de las experiencias de usuario, con los valores de relevancia, gravedad y prioridad obtenidos a partir de aplicar los criterios anteriores. 97 # Problema R G P 1 Hay falta de lenguaje inclusivo en la aplicación. 2 1 2 2 La imagen del perfil de usuario está rota. 1 3 3 3 No hay botones de navegación para volver atrás en la aplicación. 2 2 4 4 La información de las listas desplegables en filtros y formularios no está ordenada alfabéticamente. 1 2 2 5 Hay faltas de ortografía en la página web. 1 1 1 6 No se pueden ver todas las preguntas del FAQ desde el principio porque no permite la opción de plegar y desplegar. 1 1 1 7 No hay un sitio en la página web en el que se expliquen cómo se tratan los datos recogidos en la página. 1 1 1 8 Falta de interactividad con el carrusel de la página principal. 1 1 1 9 Falta de ayudas de accesibilidad en los iconos e imágenes. 1 3 3 10 Falta de cuidado en el contraste del fondo y en los textos de la aplicación. 1 3 3 11 Las páginas de Quiénes somos y Contacta son difíciles de encontrar porque están agrupadas en una lista desplegable que no ayuda a ubicarlas. 1 1 1 12 Falta de explicación de las áreas de conocimiento de la UNESCO. 3 2 6 13 No se recibe un correo de confirmación cuando se envía el formulario de registro. 1 1 1 14 No se indican los carácteres especiales soportados en la contraseña en el texto de error del formulario de registro. 3 3 9 15 Es complicado encontrar la universidad en la lista desplegable porque no están las siglas o porque no pone universidad delante del nombre en el formulario de registro. 2 3 6 16 No hay un campo que recoja la información del departamento al que pertenece un profesor o un campo de biografía para todos. 1 1 1 17 No hay un botón que permita visualizar la contraseña cuando se está escribiendo en el formulario de registro. 1 3 3 18 No se incluye la longitud mínima de la contraseña en el texto de error del formulario de registro. 1 3 3 19 No se abre la página principal desde el principio cuando envías el formulario de registro. 1 2 2 20 No se controla que las ofertas que superan la fecha límite no se deben mostrar. 1 2 2 98 21 No se indica la apropiabilidad para el alumnado según la titulación que están estudiando en las ofertas, así como las funciones que debe desempeñar el profesor y el socio comunitario en el contexto de la oferta. 1 1 1 22 Los controles de navegación del listado de ofertas, demandas y partenariados (botones de anterior y siguiente y contador) no funcionan correctamente. 2 3 6 23 El icono del ojo para visualizar una oferta, demanda o partenariado no es intuitivo y se debería sustituir por un enlace en el título del elemento. 1 2 2 24 Las ofertas, demandas y partenariados no aparecen en orden cronológico en sus respectivas listas. 1 1 1 25 El filtro de necesidad social en el listado de demandas no permite elegir varias a pesar de que es una lista desplegable en el que se pueden elegir varias opciones. 1 3 3 26 Faltan muchas titulaciones por ser incluidas. 1 2 2 27 No hay información adicional en cada uno de los campos de la oferta, de la demanda o del partenariado. 1 2 2 28 Hay ofertas que se crean a pesar de recibir un error en el formulario de creación de oferta. 1 3 3 29 Las ventanas emergentes de error no aportan retroalimentación suficiente cuando se envían formularios incorrectos. 1 3 3 30 No se controlan los valores válidos en algunos campos de los formularios. 1 3 3 31 No se contempla la posibilidad de añadir una URL externa con información ampliada de una oferta o una demanda como campo de formulario. 1 1 1 32 El campo de año académico objetivo resulta muy confuso porque se confunde con curso académico. 3 3 9 33 No hay ayuda adicional para saber qué significa cada campo de los formularios de oferta, demanda y partenariado. 3 3 9 34 El campo tag es confuso y se debería sustituir por keywords. 1 1 1 35 La explicación del campo tag que hay entre paréntesis es confusa y se debería quitar. 1 2 2 36 No se permite la opción de escribir un área de implementación personalizada. 1 2 2 37 El formulario de ofertas no te devuelve al listado de ofertas una vez lo envías y se queda en la misma página de formulario. 1 3 3 99 38 Los campos de fecha en el formulario de demanda son demasiado estrictos y deberían ser más genéricos. 3 1 3 39 No se permite la opción de escribir una necesidad social personalizada. 2 2 4 40 Los campos de demanda cuando eres profesor y de oferta cuando eres socio, así como los de información general son modificables en el formulario de partenariado. 2 3 6 41 La distribución del formulario de partenariado no es la adecuada porque los campos que no deberían ser modificables no están al principio de la sección. 2 3 6 42 El formulario de partenariado se abre con una ventana emergente con advertencia lo que puede indicarle al usuario que está haciendo algo mal cuando en realidad no es así. 1 2 2 43 El formulario de partenariado cuando aceptas a un socio no contiene algunos de los datos de la oferta que se rellenaron previamente cuando se creó la oferta. 1 3 3 44 No se muestran los campos obligatorios en los formularios de partenariado con un asterisco. 1 3 3 45 No se muestran los errores a nivel de campo y se muestran en un listado al final del formulario lo que dificulta su navegación. 1 2 2 46 No hay un apartado en el área personal que se llame Mis Notificaciones y hay que entrar en el resumen para verlo. 1 1 1 47 La campana no muestra automáticamente el número de notificaciones que tiene actualmente el usuario. 3 3 9 48 La lista de notificaciones no es accesible porque no aparece ordenada cronológicamente, no diferencia las notificaciones leídas de las no leídas y no aparecen ni las marcas temporales ni información adicional relacionada con la notificación. 3 3 9 49 La información de los partenariados no es correcta. 2 3 6 50 El nombre del partenariado no se relaciona necesariamente con el título de la oferta o demanda correspondiente, lo que resulta confuso, y encima se muestra en el título el estado del partenariado cuando no debería aparecer ahí. 2 3 6 Una vez evaluados todos los problemas, procedemos a proponer una serie de recomendaciones a cada problema, en base a las sugerencias que han ido realizando los usuarios durante las sesiones de evaluación, siempre y cuando tengan sentido y vayan en coherencia con la lógica de la aplicación. Estas recomendaciones se pueden encontrar en la tabla de a continuación, y es conveniente que a la hora de realizar los cambios en la implementación, se siga el orden de prioridad establecido. 100 # Prioridad Recomendación 14 9 Indicar, en el texto de error, los caracteres especiales que puede soportar la contraseña. 32 Cambiar el nombre del campo a curso académico objetivo, cambiar el formulario de oferta para que el campo espere recibir una cadena y no un número y realizar los cambios necesarios para que el valor recogido por este campo sea una cadena de texto y no un número. Convendría establecer un formato de cadena único, por lo que sería conveniente indicar si se debe indicar de manera yyyy-yy o yy-yy. 33 Se deberá implementar en todos los campos de todos los formularios un texto de ayuda para explicar para qué sirve ese campo y qué información recoge, así como el tipo de esta (cadena de caracteres, número, fecha, etc.) 47 Cambiar la implementación de las notificaciones de manera que el número de notificaciones salga automáticamente sin necesidad de tener que hacer click en la campana, y que el número se actualice en tiempo real sin necesidad de cargar de nuevo la página en la medida de lo posible. 48 Mostrar la lista de notificaciones ordenada de manera que las más nuevas aparezcan primero y las más viejas las últimas, implementar funcionalidad para que una notificación pueda ser categorizada como leída o no leída y separarlas en secciones diferentes, y añadir marcas temporales e información adicional relacionada con la notificación a cada notificación. 12 6 Añadir un texto de ayuda que incluya un enlace en donde se explique la clasificación que llevó a cabo el organismo y muestre la lista completa de áreas de conocimiento, para que el profesor pueda investigar cuál es la más apropiada para él. 15 O bien añadir las siglas de universidad al principio de cada universidad o bien añadir las siglas y universidad delante del nombre. Otra solución sería indicar en un texto de ayuda cómo pueden buscar su universidad adecuada o darle pistas para ello. 22 Modificar la implementación de manera que el número de ofertas, demandas y partenariados que se muestra en las listas sea el correcto. No se sabe si los botones de anterior y siguiente funcionan correctamente o bien porque todavía no hay suficientes elementos en una lista como para que tengan que ser separados en varias páginas o bien porque alomejor la implementación actual contempla que todos los elementos se muestren en la misma página. 40 Cambiar los campos correspondientes del formulario del partenariado de manera que sean no modificables, esto es, que los campos de oferta no sean modificables para un socio, que los de demanda no sean modificables para un profesor, y que los de información general no sean modificables para ninguno. 101 41 Mover los campos no modificables al principio del formulario y dejar claro qué parte del formulario es la que hay que rellenar/completar y cuáles son los datos que se cogen de la oferta o demanda correspondiente. 49 Corregir la implementación de manera que la información de cada partenariado sea la correcta. Actualmente, por lo que se ha podido observar, hay problemas especialmente con el estado (que no se actualiza correctamente) y con el área de implementación, que siempre toma el valor de análisis matemático. 50 Quitar el estado del partenariado del nombre que se muestra en la lista y no dejar modificar el nombre de la oferta o de la demanda de la que ha surgido el partenariado. 3 4 Modificar la implementación para incluir botones para ir hacia atrás en la navegación de la página web, ya que el logo de UNED solo sirve para ir a la página principal, pero no para volver hacia atrás, lo que obliga al usuario a tener que utilizar los controles del navegador. 39 En principio, se tendría que dejar la lista como está y en un texto de ayuda explicar que la necesidad social debe ser predefinida y que se debe elegir del desplegable, ya que el tener un abanico de necesidades sociales demasiado abierto provoca que sea más difícil emparejar ofertas con demandas. 2 3 Arreglar los vínculos de las imágenes. 9 Añadir textos de información de accesibilidad a todos los iconos, imágenes y vínculos de la página web 10 Cuidar los colores que se eligen de fondo de la página web y los de los textos, de manera que se vean claramente y sean legibles. En concreto, habría problemas en la barra de navegación superior, ya que el color gris sobre un fondo blanco puede ser percibido con bastantes dificultades para una persona con problemas de visión. 17 Habilitar un botón de mostrar contraseña en los campos de contraseña del formulario de registro. 18 Incluir la longitud mínima que debe tener la contraseña en el mensaje de error cuando la contraseña no es correcta. 25 O bien cambiar el filtro para que la lista desplegable solo permita elegir una necesidad social o bien arreglar el filtro actual para que se puedan elegir varias necesidades sociales, siendo mejor solución la segunda. 28 Observar la implementación para ver por qué las ofertas se crean aún cuando hay errores en los valores del formulario. En concreto, sucedió cuando un usuario introdujo una tag demasiado larga para su procesamiento, lo que provocó que saliera un error inesperado como ventana emergente, pero aún así la oferta se creaba en la lista. 29 Añadir información adicional sobre los errores del formulario en las ventanas emergentes. 102 30 Controlar la validez de los datos que se reciben en los formularios de oferta, demanda y partenariado. 37 Cambiar la implementación del formulario de oferta para que una vez se envíe correctamente, te redirija a la lista de ofertas. 38 Cambiar la implementación de manera que se dé la opción de omitir el día del mes, o incluso el mes. 43 Comprobar en la implementación por qué algunos campos no muestran algunos datos de las ofertas y demandas. Es posible que se deba precisamente a que, como no se validan, la base de datos los rechaza y se quedan vacíos. 44 Incluir un asterisco en los campos obligatorios en los formularios de partenariado. 1 2 Incluir palabras como docente en vez de profesor o alumnado en vez de alumnos. 4 Ordenar alfabéticamente la información de las listas desplegables tanto en filtros como en formularios. En caso de que haya una opción que sea “No aplicar”, dejarla o al final del todo o al principio, según el criterio que se establezca. 19 Comprobar en el formulario de registro por qué se redirige a la página principal por la mitad y no desde el principio, y modificarlo para que se visualice desde el comienzo de la página. 20 No hacer nada por ahora. 23 Se puede contemplar añadir un enlace al título para poder visualizar el elemento, pero no es recomendable quitar el icono del ojo porque viene del diseño inicial que se hizo de la página y funciona adecuadamente. 26 Cambiar la implementación para que el campo de titulaciones sea libre y se pueda escribir la que se desea. 27 Añadir información adicional a cada campo para saber qué información refleja cada uno. 35 Se puede quitar la explicación de los paréntesis y añadirla a un texto de ayuda en el que se explique mejor cómo funciona el campo y cómo se debe interactuar con él. 36 No hacer nada por ahora, ya que de momento no se contempla que se puedan añadir áreas de implementación más allá de las que hay. 42 Se puede dejar cómo está, o bien cambiar la implementación para que en vez de que salga como ventana emergente, salga como un recuadro de información al principio del formulario. 45 Cambiar la implementación de manera que los errores aparezcan a nivel de campo y no en una lista al final. 103 5 1 Corregir las faltas de ortografía. 6 Cambiar la implementación para que las preguntas sean plegables y desplegables, y que nada más cargar la página estén todas plegadas, para que el usuario pueda ver todas las preguntas que se responden en el FAQ desde el principio. 7 Se podría contemplar añadir una página en dónde se expliquen este tipo de cuestiones, pero por ahora no es necesario. 8 Añadir enlaces a cada imagen del carrusel para que se pueda interactuar con él y tenga algún propósito de usabilidad más allá del estético. 11 No agrupar las páginas en una lista desplegable y ponerlas como páginas individuales en la barra de navegación. 13 Se podría contemplar mandar un correo de confirmación en futuras implementaciones pero por ahora no es muy urgente. 16 Se podría contemplar incluir estos campos, siempre que sean opcionales. 21 Se puede indicar en un campo libre, pero será necesario un texto de ayuda para indicarlo. No tiene sentido incluir un campo de la apropiabilidad de los alumnos porque las ofertas son dirigidas a socios comunitarios. 24 Invertir el orden cronológico para que las más nuevas aparezcan al principio y las más antiguas al final. 31 Se podría contemplar incluir un campo en el que se recoja información sobre una URL para ampliar la información. 34 No cambiarlo ya que es una decisión de diseño que ya se ha tomado y se entiende bien por la mayor parte de usuario. Se puede indicar en el texto de ayuda que las tags funcionan como keywords. 46 Se podría separar la sección de las notificaciones del resumen en una página aparte que se llame Mis Notificaciones. 104 7.11. Resultados de investigación Para cerrar la experiencia de usuario, se dará respuesta a lo largo de este epígrafe a las preguntas de investigación propuestas durante la planificación, a partir de los resultados obtenidos del análisis de las métricas de interacción y el análisis de los cuestionarios. 1. ¿Cumple la aplicación el modelo mental de los usuarios? En primer lugar, como pudimos observar en el análisis de las métricas, las tareas que consistían en encontrar controles dentro de la aplicación, como puede ser la búsqueda de los listados de las ofertas, demandas, partenariados y notificaciones, así como de los botones de crear oferta y crear demanda se llevaban a cabo rápidamente, pues cada una de las tareas representaba menos del 2% del tiempo total medio que se emplea en terminar el flujo de trabajo. Sin embargo, cuando se calcularon los coeficientes de variación de los tiempos medios de los profesores, se observaron valores muy altos para algunas de estas tareas, lo que conlleva a que la representatividad de esta métrica se vea comprometida. No obstante, posteriormente se comprobó que solo uno de los siete profesores representaba un valor atípico en estas tareas, por lo que se descartó que pudiera haber algún problema grave con respecto a la búsqueda de estos controles. Por tanto, esto significa que los usuarios encuentran las cosas de manera intuitiva y donde esperan encontrarlas, por lo que durante las sesiones de interacción, se demostró que la aplicación cumplía el modelo mental de los usuarios. Además, aunque no siempre los usuarios encontraban los controles como se esperaba, como la lista de notificaciones en la campana de notificaciones, o como los listados de ofertas en la barra de navegación, la gran mayoría de ellos era capaz de ubicarlos en otros sitios, como en el Resumen del área personal o en una sección de la página principal, respectivamente. Por otro lado, también se observó que los profesores confundían el listado de ofertas personal con el listado de ofertas general, lo que provocó que la tarea de encontrar esta lista en concreto fuera la única con una tasa de usuarios que no la completan mayor que la tasa de los usuarios que la completaba, ya sea con o sin errores. No obstante, esto no debe considerarse como una desviación de la aplicación con respecto al modelo mental de los usuarios, ya que esto se debió a una interpretación incorrecta del flujo de trabajo. Además, se puede comprobar que los usuarios que interpretaban correctamente la tarea, la completaban en un tiempo medio muy reducido, como se ha comentado anteriormente. Por último, con respecto a los resultados de los cuestionarios, se observa cómo la mayoría de los usuarios están de acuerdo o completamente de acuerdo con que la aplicación presenta una interfaz intuitiva y con que se han visto capaces de utilizar la aplicación sin recibir ayuda, con un 66,6% de la muestra total en ambos casos (o lo que es lo mismo, dos terceras partes de los usuarios en total); y con que la aplicación está bien organizada y los controles son fáciles y rápidos de encontrar con un 77,7%, es decir, más de las tres cuartas partes del cómputo de usuarios global. 105 8.2. Problemas encontrados En este subcapítulo describiremos los problemas encontrados durante la realización del trabajo. Nuestro principal problema fue la necesidad de aprender y trabajar con Angular, un marco de trabajo con el que nuestro equipo no estaba familiarizado previamente. Angular es un marco muy potente y flexible para el desarrollo de aplicaciones web, pero también es complejo y multifacético, con una gran cantidad de funcionalidades y aspectos que debíamos dominar. Enfrentamos problemas tanto en la comprensión de conceptos clave como en la implementación de ciertas funcionalidades. Sin embargo, con el tiempo y a través de la persistencia, hemos podido superar estos obstáculos y desarrollar un nivel de competencia en Angular que nos ha permitido llevar a cabo nuestro trabajo. Otra de los problemas fue la instalación y configuración de la aplicación en un entorno en el que no teníamos permisos de superusuario. Esta restricción limitó nuestra capacidad para instalar ciertos paquetes o realizar ciertas configuraciones, lo que requirió que buscáramos soluciones alternativas. A pesar de estas dificultades, logramos superar este desafío y finalmente instalamos y configuramos la aplicación con éxito en el servidor que nos proporcionó la UNED. 8.3. Trabajo futuro Además de dar respuesta a las preguntas de investigación, el otro de los grandes objetivos de la experiencia de usuario fue el de elaborar una lista de problemas que iban surgiendo según los usuarios utilizaban la herramienta. A partir del análisis de los comentarios recibidos de los usuarios, tanto durante la interacción con la aplicación como en la entrevista de debriefing, pudimos obtener un listado de hasta 50 fallos, estableciendo su prioridad a partir de la relevancia que los usuarios le otorgaban (es decir, el número de veces que se repetía ese error por usuarios diferentes) y la gravedad del problema per se. Esa recopilación de problemas, categorizados por su prioridad, así como las recomendaciones que se proponen para cada problema, se encuentran en el informe de hallazgos y recomendaciones, que corresponde al epígrafe 10 del capítulo 7. No obstante, de cara a este epígrafe, recapitulamos algunos de los más importantes a continuación: ● Notificaciones: El número de notificaciones se tendría que ver actualizado automáticamente en el icono de la campana sin necesidad de tener que hacer click previamente, y hay que mejorar el diseño del listado de notificaciones de manera que esté ordenado cronológicamente de más nueva a más antigua, diferenciar las leídas de las no leídas y añadir información relevante que permita diferenciar una notificación del resto. ● Formularios: Los formularios deberían validar los datos introducidos en los campos, además de dar información adicional sobre qué es lo que se espera que reciba cada campo para darle más facilidades al usuario. Además, el 112 control de errores de algunos campos debe mejorarse, y se debe reconsiderar la implementación de otros. ● Listados de ofertas, demandas y partenariados: El contador de los listados de ofertas, demandas y partenariados debería mostrar el número correcto de elementos que existen en la herramienta. Además, las listas se tendrían que ordenar cronológicamente, mostrando primero los elementos que se han creado recientemente. ● Accesibilidad de la página: Las faltas de ortografía se deben corregir, al igual que se debería contemplar el lenguaje inclusivo a la hora de redactar la información contenida en la página web. Además, se debe mejorar la navegación y la accesibilidad de la herramienta. 113 Capítulo 9 Conclusions and future work In this same chapter we are going to talk about the objectives that have been met in this work, and also about the possible implementations that could be carried out in the future. 9.1. Conclusions Throughout the duration of this Final Degree Project, a series of important development milestones have been achieved, which have substantially improved the functionality and usability of the Service-Learning (ApS) application. Major achievements include: ●Complete implementation of flows for the creation of partnerships:One of the significant achievements of this Final Degree Project (TFG) has been the comprehensive implementation of the flows for the formation of partnerships. This involved not only creating forms for each flow, but also incorporating sophisticated logic for handling offers and requests in order to successfully create the partnership. ●The implementation of the views for the detailed visualization of the partnerships:These views provide a comprehensive representation of each partnership, including information on the responsible teacher, the title of the partnership, the status it is in, a detailed description of the partnership, a negotiation chat between the teacher and the community partner, and buttons that remain. to finish to turn the partnership into an active project. The teacher now has the ability to explore partnerships in depth, gaining a clear understanding of their scope, purpose, and progression. ●Implementation of a notification system:An efficient notification system was developed. This system alerts users to relevant updates and changes to application processes. Notifications may include information about new bid-ask pairings, status updates on existing partnerships, and any other relevant changes that may require user attention. ●Implementation of a modal view for notifications:Achieved by creating a popup with a scrollable section that appears without having to leave the current page or view. This notification modal displays relevant information to the user, such as notifications of status updates, or successful matches in the case of this job. ●Implementation of a user profile with detailed data: The user profile contains more detailed data about each user. The profiles provide a comprehensive view of 114 the user, including the sector to which it belongs, the page, its mission and the user's personal data. ●Extending the Data Domain Model:Throughout this TFG, extensive work has been done to expand the data domain model of the application. These efforts have ensured that the system is capable of handling a broader range of data and situations, increasing its versatility and its ability to adapt to the changing needs of users and the Service-Learning community. ●Assembly and deployment of the application:The assembly and deployment of the application has been carried out, allowing its accessibility and use by users. This process included setting up the servers, installing the application, and running extensive tests to ensure that the application works efficiently and smoothly. The application is now available for use in a real environment, marking an important milestone in the development and expansion of the Service-Learning platform. ●Automate the process of matching offers and demands:The matching algorithm developed in the TFG of the 2020-21 academic year has been automated. This feature has been programmed to run autonomously on the server, running daily at midnight. This advance provides a notable improvement in the efficiency of the system, since it is in charge of collating and matching offers and demands without requiring any manual intervention. The result is greater comfort for users and optimization in the use of system resources. ●The correction of errors detected in the previous TFG:Last but not least, a detailed analysis of the code has been carried out, and several problems have been identified and solved. These errors ranged from problems with the filtering logic to incorrect display of partnership information. Resolving these issues has improved the functionality and stability of the app. This bug fixing work has required a deep understanding of the existing code. The detailed list of bugs found and solutions implemented can be found in Appendix 1. Transparency in this area is essential to ensure that future work can continue effectively. On the other hand, the conclusions that are drawn from the user experience are observed from the answers to the research questions, which were obtained through the results obtained during the analysis of data collected in the user evaluation sessions. Although the conclusions obtained from the user experience were developed in detail in the research results, contained in the eleventh section of chapter 7, we will briefly review them in the following lines: ●The application meets the mental model of the users, since the tasks that require locating the controls of the tool were generally completed quickly and intuitively, and the majority of users considered that they agreed, to a lesser or greater degree. that the application has an intuitive interface, that they had been able to interact with it without help, and that the tool is well organized and its controls are easy and quick to find. ●Teachers are able to complete the tasks in the workflow in an acceptable time, since on the one hand the overall rates of completed tasks without errors are higher 115 than the overall rates of completed tasks with errors or not completed and on the other hand, more Half of the teachers complete more than half of the tasks within acceptable margins compared to the times of the rest and, in general, all of them complete the workflow within the established limits. ●Community partners are able to complete the tasks in the workflow, but it cannot be determined if they do so in an acceptable time, because even though the overall task completion rate without errors is higher than the task completion rate with errors, the sample is not large enough to study the variation of times in a representative way. ●The vast majority of users consider that the application is useful for them, since despite not sharing that the tool helps them maintain their privacy, they do agree that using it allows them to save time and money, do what they are looking for more quickly and because they can interact with it with a certain degree of independence, in addition to finding it quite beneficial on a general level. ●Users find the application easy to use, as users completed the vast majority of tasks without errors, and generally agreed that when they did make mistakes, they easily recovered from them, that they did not need outside help to complete the flow. of work and in general terms, they were strongly in favor of the general ease of use of the tool. ●The application is appropriate according to users, since the vast majority of them consider that the application covers a need and that, in general, the application is adequate for its purpose. ●The degree of satisfaction for users after interacting with the application is considerably high, since in general, they state that they liked using it, that they would recommend it to other people interested in Service-Learning, and that they would use it again in the future. if they needed it. 8.2. Problems encountered In this subchapter we will describe the problems encountered during the performance of the work. Our main issue was the need to learn and work with Angular, a framework our team was previously unfamiliar with. Angular is a very powerful and flexible framework for developing web applications, but it is also complex and multifaceted, with a lot of functionality and aspects that we needed to master. We faced problems both in understanding key concepts and in implementing certain functionalities. However, over time and through persistence, we have been able to overcome these obstacles and develop a level of proficiency in Angular that has allowed us to get our work done. Another problem was installing and configuring the application in an environment where we did not have root permissions. This restriction limited our ability to install certain packages or perform certain configurations, which required us to look for workarounds. Despite these difficulties, we managed to overcome this challenge and finally successfully installed and configured the application on the server provided to us by UNED. 116 8.3. Future work In addition to answering the research questions, the other major goal of the user experience was to draw up a list of problems that arose as users used the tool. From the analysis of the comments received from the users, both during the interaction with the application and in the debriefing interview, we were able to obtain a list of up to 50 bugs, establishing their priority based on the relevance that the users gave them (that is, that is, the number of times that error was repeated by different users) and the severity of the problem per se. This compilation of problems, categorized by their priority, as well as the recommendations proposed for each problem, can be found in the report of findings and recommendations, which corresponds to section 10 of chapter 7. However, for this section, we recapitulate some of the most important below: ●Notifications: The number of notifications should be automatically updated in the bell icon without having to click previously, and the design of the list of notifications must be improved so that it is ordered chronologically from newest to oldest, differentiate the read from the unread and add relevant information that allows differentiating a notification from the rest. ●Forms: The forms should validate the data entered in the fields, in addition to giving additional information about what each field is expected to receive to make it easier for the user. Also, error handling of some fields should be improved, and the implementation of others should be reconsidered. ●Lists of offers, demands and partnerships: The counter of the lists of offers, demands and partnerships should show the correct number of elements that exist in the tool. Also, the lists would need to be ordered chronologically, showing the most recently created items first. ●Page accessibility: Misspellings must be corrected, just as inclusive language should be considered when writing the information contained on the web page. In addition, the navigation and accessibility of the tool should be improved. 117 Capítulo 10 Contribuciones al proyecto 10.1. Carlos García Vaquero Durante la primera fase del proyecto, se investigó sobre Aprendizaje-Servicio a través de la lectura de la memoria de los Trabajos de Fin de Grado de años anteriores. Además, a través de unos apuntes facilitados por Manuel Montenegro Montes, y una bibliografía propuesta por Simon Pickin, ambos tutores de este trabajo, se interiorizaron las tecnologías necesarias para poder seguir con la implementación de la aplicación web. En la segunda etapa, se realizó la instalación local del proyecto, y se instaló el software necesario para comenzar a trabajar con el desarrollo de la herramienta, como Docker y Node.js. Sin embargo, se encontraron varias dificultades a la hora de familiarizarse con Docker, ya que era una herramienta completamente nueva para mí y no sabía cómo funcionaba. En la tercera etapa, se analizó de forma minuciosa el código de la aplicación, lo cual me supuso probablemente uno de los mayores desafíos a los que me he tenido que enfrentar durante este trabajo, en primer lugar por no estar muy familiarizado con los lenguajes de JavaScript (y por lo tanto, tampoco con Node.js), ni con Angular, y en segundo lugar, por la extensión tan grande del proyecto. Durante las cuarta y quinta fases del proyecto, me dediqué a realizar pequeñas contribuciones al código del proyecto, como por ejemplo la implementación del perfil del socio o del profesor, de manera que fueran accesibles desde la vista de una notificación, y a corregir algunos errores a nivel de interfaz. Mi participación fue tan reducida porque durante las siguientes fases, me dedicaría plenamente a planificar, diseñar y desarrollar la experiencia de usuario que llevaríamos a cabo, así como del análisis de datos que se realizaría a partir de esta, con el objetivo de analizar la usabilidad y la utilidad de la aplicación que estábamos desarrollando, así como de obtener una lista de problemas y errores. En la sexta fase del proyecto, se inició la experiencia de usuario con un brainstorming, es decir, se comenzaron a proponer numerosas ideas sobre cómo se debía proceder con la planificación de la experiencia, delimitar los propósitos principales, contemplar todos los escenarios en los que se podían desarrollar las sesiones de evaluación, así como las posibles tareas que tendría que llevar a cabo como moderador, se propusieron algunos nombres como posibles futuros participantes de la experiencia y se identificaron todos los perfiles de usuario que podrían participar en la misma. Todas estas propuestas, que iban surgiendo en las reuniones con los tutores o bien a través del correo electrónico, se iban reflejando en un documento para posteriormente incluirlas en la memoria. 118 Durante la séptima fase del proyecto, se delimitaron los propósitos principales de la experiencia de usuario y se comenzó a pensar en la posible estructura de esta. Gracias a los conocimientos adquiridos durante la asignatura de Desarrollo de Sistemas Interactivos, que precisamente había cursado durante el primer cuatrimestre, no me fue necesario documentarme excesivamente sobre la teoría y la metodología que se suele utilizar para llevar a cabo una buena experiencia de usuario y no tuve muchos inconvenientes a la hora de concretar los objetivos ni las preguntas de investigación, pero fue necesario invertir un tiempo considerable en su definición, ya que estas marcarían el contexto y el futuro del resto de la experiencia, por lo quera necesario establecer una hoja de ruta apropiada para posteriormente conseguir unos resultados de los que se pudieran extraer unas conclusiones apropiadas. En la octava fase del proyecto, y una vez establecidos los objetivos, se terminó el diseño de la planificación de la experiencia de usuario, para lo que fue necesario delimitar los destinatarios finales de la experiencia de usuario acorde con el nivel de implementación al que se había llegado, por lo que se tuvieron que descartar los perfiles que todavía no pueden interactuar con la aplicación, se definieron las tareas definitivas que llevaría a cabo el moderador durante las sesiones de evaluación, se establecieron los escenarios aceptables y no aceptables bajo los cuales se desarrollarían las sesiones de evaluación, así como las normas para los participantes y se definió la metodología de análisis para los datos que se iban a recoger. Durante la novena fase del proyecto, después de que Simon y Ángeles Manjarrés realizaran la búsqueda de posibles participantes para la experiencia de usuario, se estableció el primer contacto con ellos vía correo electrónico para tantear las fechas en las que realizar las sesiones de evaluación, así como la modalidad que preferían. Una vez se llegaba a un acuerdo, se les enviaba una explicación breve acerca de en qué consistiría la experiencia de usuario, las herramientas que tendrían que tener preparadas para realizarlas, y se les pedía el consentimiento para grabar la sesión para su posterior análisis. Mientras que se planificaban las sesiones, y una vez se finalizó con el desarrollo de la aplicación por parte de mis compañeros, se decidió poblar la base de datos con ejemplos reales de ofertas y demandas, para dotar de verosimilitud a la aplicación, se definieron los flujos de trabajo con las tareas que tendrían que realizar los profesores y los socios comunitarios, y se elaboraron las preguntas del cuestionario y de la entrevista de debriefing. Previamente a las sesiones de evaluación, también se confeccionó una plantilla de manera que permitiera recoger toda la información necesaria para el posterior análisis de datos. Posteriormente, atendí en calidad de moderador a todas las sesiones de evaluación programadas, asumiendo las tareas correspondientes. Además, mientras interactuaban con la aplicación, se recogía toda la información pertinente rellenando las plantillas, y luego revisando las grabaciones en caso de que fuera necesario. Finalmente, en la última fase del proyecto, llevé a cabo el análisis de los datos recogidos durante las sesiones de evaluación, que comprendían las métricas de interacción, los comentarios recibidos por los usuarios y los resultados obtenidos a partir del cuestionario. Una vez se completó el análisis, se procedió a elaborar la lista de problemas encontrados y las recomendaciones propuestas, así como a extraer los resultados de investigación, las conclusiones y a redactar las partes de la memoria que me correspondían. 119 10.2. Feiyun Ye En el inicio de este proyecto, la prioridad fundamental era adquirir una sólida comprensión teórica del Aprendizaje-Servicio. Para lograr este objetivo, llevé a cabo una lectura exhaustiva de las memorias de Trabajos de Fin de Grado de ciclos académicos previos, revisando detenidamente los materiales didácticos proporcionados por nuestros tutores, Manuel Montenegro y Simon Pickin. Este estudio preliminar, complementado con la lectura de la de los materiales didácticos, me permitió familiarizarme con las tecnologías claves que serían necesarias para la posterior implementación de la aplicación web. Durante la segunda fase del proyecto, procedí a la instalación del proyecto en un entorno local y a configurar también el marco de trabajo para poder realizar las pruebas necesarias de esta aplicación. Este proceso implicó la instalación de Docker, Node.js y Angular. Presentó desafíos propios, dado que Docker era una tecnología con la que ningún miembro del equipo teníamos experiencia previa por lo que tuve que echar una mano a mis compañeros con el tema de instalación. Además entender su funcionamiento y cómo usarlo de manera efectiva requirió un esfuerzo de aprendizaje significativo para mí. En la tercera fase del proyecto, emprendí un análisis minucioso del código fuente de la aplicación. Este labor se reveló especialmente ardua, debido a mi falta de experiencia previa con los lenguajes de JavaScript. A esto se añadió la complejidad inherente de un proyecto de tal magnitud. Sin embargo, a pesar de estos desafíos, conseguí adquirir un entendimiento del código y parte de su estructura, lo que me permitió realizar el chequeo de las funcionalidades implementadas y listar aquellas que no se han implementado hasta ahora. En la cuarta fase del proyecto, llevé a cabo una serie de discusiones colaborativas con mis compañeros para definir lo que se necesitaría para iniciar la creación de partenariados. Este proceso incluyó la validación con nuestros tutores de la necesidad de expandir la base de datos para acomodar funcionalidades adicionales. Una vez acordados los detalles, procedí a diseñar e implementar las nuevas tablas en la base de datos, asegurando el correcta establecimiento de las relaciones pertinentes. En la quinta fase del proyecto, asumí el rol de diseño e implementación de varios elementos de visualización, incluyendo la campana de notificaciones, la barra de desplazamiento, los botones, y las casillas de verificación. Esto implicó la modificación de los archivos component.html y component.scss correspondientes. Además, llevé a cabo la implementación completa del sistema de notificaciones. Esto incluyó el diseño de los componentes de la notificación, representados en los archivos notificacion.component.html, notificacion.component.scss, así como ajustes en navbar.component.html y .ts. Durante este punto del proyecto, investigué más a fondo la funcionalidad de creación de partenariados. Al estar en modo de pruebas, llegué a la conclusión de que esta funcionalidad, aunque útil como referencia, requería de ajustes significativos para ser verdaderamente funcional. Procedí a solucionar problemas con los formularios que previamente no podían ser visualizados. Para ello, establecí una relación entre las notificaciones de aceptación de oferta y los partenariados, teniendo en cuenta las posibles diferencias que podrían surgir en situaciones futuras. La solución pasó por el uso de 120 parámetros de URL para marcar las diferencias. Descubrí que el mapeo de las notificaciones en el servidor estaba incorrecto, lo cual impedía el correcto funcionamiento del sistema de notificaciones. Me encargué de corregir este problema para que las notificaciones pudieran ser enviadas y recibidas correctamente. Finalmente, implementé una comprobación que garantiza que, si un partenariado se ha creado correctamente, se envía una solicitud al backend para crear una nueva notificación para el socio. Si el partenariado no se ha creado correctamente, el sistema advierte al usuario del problema. En la sexta fase del proyecto, continué con la creación de partenariados para el itinerario 2. Tuve que determinar si era necesario incluir información de las ofertas del itinerario 1, lo que me condujo a una reestructuración de esta sección para adaptarla a las necesidades del proyecto. Además, procedí a dividir el formulario existente en tres secciones distintas: oferta, demanda y completa, preparándolas para su uso futuro. En esta fase también me centré en el estudio del despliegue de la aplicación. Este proceso se mostró desafiante debido a la falta de permisos de superusuario, que impedían el uso del comando 'sudo'. Esta limitación dificultó las instalaciones necesarias y, junto con un conocimiento inicial limitado sobre el despliegue de aplicaciones, añadió una capa extra de complejidad a esta tarea. A pesar de estas dificultades, seguí investigando y aprendiendo para avanzar en este aspecto crucial del proyecto. En la séptima fase del proyecto, mi enfoque principal fue el despliegue de la aplicación en el servidor proporcionado por la UNED. Este proceso implicaba gestionar el servidor de forma remota, lo que logré mediante el uso de la herramienta PuTTY, que me permitió acceder al servidor a través del protocolo SSH proporcionado. A continuación, cloné el repositorio de GitHub en el servidor e importé la base de datos en el mismo. Este proceso, sin embargo, no estuvo exento de desafíos. Me encontré con varios obstáculos durante el despliegue de la aplicación, los cuales pude resolver gracias a la invaluable ayuda de los directores del proyecto, Manuel y Simon. Finalmente, y a pesar de los contratiempos, logré desplegar la aplicación con éxito en el servidor. En la octava fase del proyecto, nos preparamos para realizar una experiencia de usuario. Esto nos llevó a perfeccionar nuestros servicios ya que, inicialmente, había problemas con la recepción correcta de mensajes y la visualización y creación de demandas en la web. Me hice cargo de solucionar estos problemas de visualización de mensajes. Además, trabajé en la automatización del algoritmo de emparejamiento en el servidor. Para conseguir esto, utilicé el comando 'cron' en el servidor. Esta tarea garantiza que el proceso de emparejamiento se ejecutará de forma regular y sin intervención manual. En la novena fase del proyecto, tanto mi compañera Shuyi como yo, decidimos colaborar con nuestro compañero Carlos, dedicando tiempo a corregir los filtros de "Mis Ofertas" y "Mis Demandas". Enfrentamos varias restricciones en cuanto a las demandas, y trabajamos en la mejora de los textos de muestra. Al mismo tiempo, comenzamos a trabajar en la redacción de la memoria del proyecto. Este proceso implicaba recopilar y organizar toda la información relacionada con nuestro trabajo, desde la concepción inicial hasta las diversas fases de implementación, así como documentar cualquier dificultad y solución que encontramos en el camino. 121 128 ●Textos de botones confusos: Algunos botones en la aplicación tenían textos que no reflejaban con precisión su función. Por ejemplo, había botones etiquetados como "Aceptar oferta" en el proceso de creación de un partenariado, lo que podría llevar a confusión. Se realizó una revisión detallada de todos los textos de los botones y se modificaron para reflejar con precisión su función correspondiente. ●Control de roles: Se detectó que algunos botones y funciones estaban disponibles para roles de usuario inapropiados. Por ejemplo, los botones para crear demandas u ofertas podrían ser vistos y utilizados por roles que no deberían tener estos privilegios. Para solucionar este problema, se desactivó el botón para restringir estas funcionalidades a roles inadecuados. ●Presentación de datos: En algunas partes de la aplicación, la presentación de datos no era precisa. En particular, en las secciones de "Mis ofertas", "Mis demandas" y "Mis partenariados", se mostraban todos los elementos disponibles en lugar de sólo los pertenecientes al usuario. Además, en la página de partenariados, la finalidad se mostraba como el nombre del partenariado. Para solucionar estos problemas, se corrigió la lógica de presentación de datos para asegurar que se muestren los datos correctos en cada contexto. Implica revisión del código de lectura de la clase de DAOpartenariado. 129 Apéndice 2 Cuestionario P1. Introduce tu nombre y apellidos. P2. ¿Desde qué perspectiva has utilizado la aplicación? ○ Profesor ○ Socio comunitario P3. La aplicación me ha parecido útil porque me permite hacer lo que busco ahorrándome tiempo y dinero. 1 2 3 4 5 Muy en desacuerdo ○ ○ ○ ○ ○ Muy de acuerdo P4. La aplicación me ha parecido útil porque me permite hacer lo que busco de manera más rápida. 1 2 3 4 5 Muy en desacuerdo ○ ○ ○ ○ ○ Muy de acuerdo P5. La aplicación me ha parecido útil porque me permite hacer lo que busco manteniendo mi privacidad. 1 2 3 4 5 Muy en desacuerdo ○ ○ ○ ○ ○ Muy de acuerdo P6. La aplicación me ha parecido útil porque me permite hacer lo que busco por mí mismo sin involucrar a nadie más. 1 2 3 4 5 Muy en desacuerdo ○ ○ ○ ○ ○ Muy de acuerdo 130 P7. En general, la aplicación me ha parecido útil. 1 2 3 4 5 Muy en desacuerdo ○ ○ ○ ○ ○ Muy de acuerdo P8. La aplicación presenta una interfaz intuitiva. 1 2 3 4 5 Muy en desacuerdo ○ ○ ○ ○ ○ Muy de acuerdo P9. La aplicación está bien organizada y los controles son fáciles y rápidos de encontrar. 1 2 3 4 5 Muy en desacuerdo ○ ○ ○ ○ ○ Muy de acuerdo P10. He sido capaz de usar la aplicación sin recibir ayuda o explicaciones adicionales. 1 2 3 4 5 Muy en desacuerdo ○ ○ ○ ○ ○ Muy de acuerdo P11. Cada vez que he cometido un error utilizando la aplicación, me recuperaba fácil y rápidamente. 1 2 3 4 5 Muy en desacuerdo ○ ○ ○ ○ ○ Muy de acuerdo P12. En general, la aplicación es fácil de utilizar. 1 2 3 4 5 Muy en desacuerdo ○ ○ ○ ○ ○ Muy de acuerdo 131 P13. Creo que utilizar esta aplicación es una buena idea. 1 2 3 4 5 Muy en desacuerdo ○ ○ ○ ○ ○ Muy de acuerdo P14. En mi opinión, la aplicación cubre una necesidad. 1 2 3 4 5 Muy en desacuerdo ○ ○ ○ ○ ○ Muy de acuerdo P15. La aplicación es adecuada y apropiada. 1 2 3 4 5 Muy en desacuerdo ○ ○ ○ ○ ○ Muy de acuerdo P16. Me ha gustado utilizar la aplicación. 1 2 3 4 5 Muy en desacuerdo ○ ○ ○ ○ ○ Muy de acuerdo P17. Recomendaría la aplicación a otras personas. 1 2 3 4 5 Muy en desacuerdo ○ ○ ○ ○ ○ Muy de acuerdo P18. En general, volvería a utilizar esta aplicación si lo necesitara. 1 2 3 4 5 Muy en desacuerdo ○ ○ ○ ○ ○ Muy de acuerdo 132 Apéndice 3 Desarrollo de las sesiones de evaluación por usuario Usuario: Profesora en la Facultad de Educación de la UNED Nivel informático: Medio Nivel ApS: Medio Tarea Estado Tiempo Comentarios Búsqueda de información Completada con errores 7m15s Echa de menos un botón en la página para volver para atrás porque no se da cuenta de que el logo de la UNED de la esquina superior izquierda hace esa función. Le gusta como está redactada la información. Registro Completada con errores 6m50s Menciona que es importante que los campos sean más sensibles al lenguaje y contenga palabras más inclusivas (por ejemplo, docente en vez de profesor). En el campo de la contraseña, convendría especificar qué carácteres especiales se contemplan, ya que el + no le ha servido. Valora que salga un desplegable en el campo de la universidad, pero no es capaz de encontrar su universidad porque la busca como UNED o como Universidad Nacional de Educación a Distancia. Sugiere que se ponga las siglas y Universidad antes del nombre en todas las universidades para evitar este problema. Login Completada sin errores 30s No entiende lo que significa SSO UNED. Encontrar listado de ofertas Completada sin errores 5s Explorar listado de ofertas Completada con errores 2m30s Intenta hacer click en el título de la oferta para consultarla en vez de darle al icono del ojo. Encontrar botón de crear oferta Completada sin errores 5s La encuentra rápidamente y le parece genial que esté tan a mano. 133 Rellenar formulario de oferta Completada con errores 9m20s En el área de implementación, intenta ingresar Educación infantil sin éxito. Valora positivamente que se generen automáticamente las tags, pero se frustra porque borra las que no le gustan y cuando intenta escribir más tags, las escribe en un bloc de notas externo, por lo que al volver a hacer click le vuelve a generar las tags que había borrado antes. Le confunde el campo año académico objetivo y decide escribir un curso académico en vez de un año. Le despista que al rellenar el formulario, no la devuelva al listado de ofertas creadas y vuelva a salir un formulario con los campos vacíos. Encontrar listado de ofertas personal No completada x Confunde listado de ofertas general con listado de ofertas personal. Encontrar listado de demandas Completada sin errores 5s No termina de entender bien el concepto de oferta y demanda y al principio no es capaz de diferenciarlas. Además, al principio piensa que se trata de ofertas a alumnos y no a socios comunitarios. Explorar listado de demandas con filtros Completada sin errores 4m30s Cuando interactúa con el filtro de Necesidad social, se pregunta por qué ese campo no estaba en el formulario de oferta, porque no termina de entender la diferencia entre oferta y demanda. Se queja de que ‘No aplicar’ esté en el medio de la lista del desplegable y que el resto no esté ordenado alfabéticamente. El desplegable de Área de servicio se corta en Mozilla Firefox por culpa del footer y no le permite ver algunas opciones de la lista. No entiende bien las diferencias entre fecha de inicio y fin de la demanda para definición y ejecución. Rellenar formulario de partenariado (respalda de demanda) Completada con errores 7m20s Nada más comenzar a observar el formulario, no entiende por qué hay datos ya en algunos campos y piensa que esa información viene de la oferta que había creado previamente (y no de la demanda que está respaldando) Menciona que los datos en Información general no deberían ser modificables, así que decide no tocarlos. En vez de seleccionarse como parte del equipo de profesores, selecciona a otros 134 profesores, por lo que no está entendiendo realmente para qué sirve el formulario. Vuelve a escribir un curso académico en vez de un año académico. Luego intenta modificar datos de la demanda pero se da cuenta que esos campos no se pueden modificar. Cuando entiende en qué consiste el formulario, sugiere que la parte de Información demanda debería estar al principio del formulario para entender desde un principio para qué sirve el formulario. Búsqueda de lista de notificaciones Completada sin errores 30s Se queja de que el número de notificaciones aparezca una vez pinchas en la campana pero no desde el principio. Explorar lista de notificaciones (búsqueda de notificación de oferta aceptada) Completada con errores 1m45s No encuentra la notificación a la primera y revisa una a una todas las notificaciones. Comprobar datos del socio No completada x Acepta al socio directamente sin comprobar sus datos. Rellenar formulario de partenariado (completar datos de oferta) No completada x No le deja modificar los datos de la oferta, y como ha escrito mal el año académico en vez de un curso académico, el campo aparece vacío y no modificable, por lo que no puede completar el formulario ya que es obligatorio. Explorar lista de notificaciones (búsqueda de notificación de partenariado creado) No completada x No puede realizar esta tarea porque para ello necesitaría completar la tarea anterior. Encontrar listado de partenariados personal No completada x Confunde listado de partenariados general con listado de partenariados personal. Solo aparece un partenariado de los dos que se deberían haber creado. Métricas Número de tareas totales 17 Número de tareas completadas sin errores 6 Tasa de tareas completadas sin errores 35,3% 135 Número de tareas completadas con errores 6 Tasa de tareas completadas con errores 35,3% Número de tareas sin completar 5 Tasa de tareas sin completar 29,4% Tiempo total empleado 40m45s Comentarios adicionales (entrevista): ● Echa de menos en el formulario de registro un campo para escribir el departamento al que pertenece. ● Los campos de los formularios de partenariado que no se pueden modificar deberían aparecer arriba del todo para no confundirse. ● Añadir un texto de ayuda a cada campo del formulario para que el usuario sepa para qué sirve cada campo y qué valor espera recibir ya que la aplicación utiliza un lenguaje muy específico que no todo el mundo maneja. Usuario: Profesora en la Facultad de Educación de la UNED Nivel informático: Usuario Nivel ApS: Medio Tarea Estado Tiempo Comentarios Búsqueda de información No completada x No encuentra la sección de perfiles en la página principal y se le tiene que indicar que puede usar la barra de desplazamiento vertical para bajar abajo, a lo que responde que está acostumbrada a ver todos los elementos de una página web en la pantalla sin tener que bajar o subir. Registro No completada x Escribe UNED en en la universidad y se queja de que no lo reconozca, opina que poner Nacional de Educación a Distancia sin Universidad delante y sin las siglas es poco intuitivo. Completa el formulario sin errores pero le da error inesperado al registrarse, por lo que no completa el registro. Login Completada sin errores 5s Encontrar listado de ofertas Completado con errores 2m No ha observado la barra de navegación de arriba y ha encontrado la lista de ofertas, curiosamente, en una de las secciones de la página principal. Explorar listado de ofertas Completado sin errores 2m30s Intenta hacer click en anteriores y siguientes porque se piensa que hay 136 más ofertas, ya que el contador que aparece está mal. Encontrar botón de crear oferta Completado sin errores 5s Rellenar formulario de oferta Completado con errores 8m Escribe un curso académico en vez de un año académico. Encontrar listado de ofertas personal No completada x Confunde listado de ofertas personal con listado de ofertas general. Encontrar listado de demandas Completado sin errores 5s Explorar listado de demandas con filtros Completado sin errores 7m Rellenar formulario de partenariado (respalda de demanda) Completado con errores 5m45s Comenta que los campos de la demanda aparecen editables cuando no deberían serlo. Vuelve a rellenar mal el campo de año académico poniendo un curso en vez de un año natural. Le confunde bastante la distribución del formulario y no entiende exactamente para qué sirve y qué campos tiene que rellenar, sugiere que los campos que no se deberían modificar aparezcan al principio. Búsqueda de lista de notificaciones Completado sin errores 5s No le gusta que no aparezca el número de notificaciones actualizado. Explorar lista de notificaciones (búsqueda de notificación de oferta aceptada) Completado con errores 1m30s No encuentra la notificación a la primera y revisa una a una todas las notificaciones. Comprobar datos del socio No completado x Acepta al socio directamente sin comprobar sus datos. Rellenar formulario de partenariado (completar datos de oferta) Completado con errores 2m10s Vuelve a escribir el año académico como curso académico. Explorar lista de notificaciones (búsqueda de notificación de Completado con errores 1m30s No aprende de la exploración anterior que las notificaciones más recientes están al final, por lo que explora todas las notificaciones otra vez. Es capaz de 137 Nacional después de probar que Universidad no le da resultados. Expresa su preocupación por no encontrar ningún área de conocimiento de la UNESCO que se adecúe con su perfil, pero finalmente encuentra uno apropiado para él. Echa de menos recibir un correo de confirmación. Login Completada sin errores 10s Encuentra el login sin problemas. Al principio duda si el correo que aparece en el flujo debería recibirlo o no, pero se le explica que es una suposición. Encontrar listado de ofertas Completada sin errores 5s Explorar listado de ofertas Completada sin errores 2m Asume que las ofertas que superan la fecha límite deberían desaparecer de la aplicación. Echa en falta que de manera explícita se indique la apropiabilidad de la oferta para el alumnado según la carrera que tengan. Encontrar botón de crear oferta Completada sin errores 5s Rellenar formulario de oferta Completada con errores 4m10s Escribe una tag demasiado larga y el formulario manda un error, aunque la crea por debajo. Acorta el título y prueba otra vez pero le da error. Prueba a quitar una tag demasiado larga, vuelve a probar y se crea correctamente. Encontrar listado de ofertas personal Completada sin errores 5s Encuentra la lista en el perfil. Se encuentra la oferta 4 veces creada. Encontrar listado de demandas Completada sin errores 5s Explorar listado de demandas con filtros Completada sin errores 2m Rellenar formulario de partenariado (respalda de demanda) Completada sin errores 2m10s Búsqueda de lista de notificaciones Completada sin errores 5s Le parece bien la campanita y le parece intuitivo, pero cree que debería haber también un apartado de Mis Notificaciones en el área personal. Explorar lista de Completada 5s Se equivoca de notificación y mira la de 144 notificaciones (búsqueda de notificación de oferta aceptada) con errores una oferta que no es la suya. Se le indica que debe mirar la suya. Comprobar datos del socio Completada sin errores 5s Le parece muy intuitivo el enlace. Rellenar formulario de partenariado (completar datos de oferta) Completada sin errores 20s No entiende la casilla de externo. Explorar lista de notificaciones (búsqueda de notificación de partenariado creado) Completada sin errores 5s Encuentra la notificación sin problemas. Intenta convertirlo en proyecto pero se da cuenta de que esa funcionalidad no está implementada todavía. Encontrar listado de partenariados personal Completada sin errores 5s La encuentra perfectamente. Aparecen los dos partenariados creados. Métricas Número de tareas totales 17 Número de tareas completadas sin errores 15 Tasa de tareas completadas sin errores 88,2% Número de tareas completadas con errores 2 Tasa de tareas completadas con errores 11,8% Número de tareas sin completar 0 Tasa de tareas sin completar 0% Tiempo total empleado 19m10s Comentarios adicionales (entrevista): ● Que la oferta tuviera un enlace para poder ampliar la información de manera externa. ● Considera que esta todo muy bien organizado y planteado, pero alomejor le parece un poco más complejo consultar los partenariados pero no excesivamente. ● En los errores debe aportar algún tipo de retroalimentación. ● Considera que la herramienta es muy útil y está muy bien pensada y enfocada y parece bastante contento y entusiasmado con la aplicación. 145 Usuario: Profesora de la E.T.S. de Minas y Energía de la UPM Nivel informático: Alto Nivel ApS: Alto Tarea Estado Tiempo Comentarios Búsqueda de información Completada sin errores 7m Encuentra la información sin problemas. Sugiere que se incluya lenguaje inclusivo (estudiante en vez de alumnos…). Registro Completada con errores 5m10s Tiene problemas al escribir la contraseña por el caracter especial. Le cuesta encontrar la universidad, hay problemas con el desplegable. No ve muy claro las áreas de conocimiento de la UNESCO. Login Completada sin errores 5s No tiene ningún problema en encontrar el Login e inicia sesión correctamente. Encontrar listado de ofertas Completada sin errores 5s Lo encuentra sin problemas. Explorar listado de ofertas Completada sin errores 2m50s Le falta información en las ofertas. Encontrar botón de crear oferta Completada sin errores 5s Encuentra el botón perfectamente. Rellenar formulario de oferta Completada sin errores 3m25s No hay ningún problema mientras rellena el formulario. Encontrar listado de ofertas personal No completada x Confunde listado general con listado personal. Encontrar listado de demandas Completada sin errores 5s Lo encuentra sin problemas. Explorar listado de demandas con filtros Completada sin errores 2m No hay problemas a la hora de interactuar con esta tarea. Rellenar formulario de partenariado (respalda de demanda) Completada con errores 2m25s Pone curso académico en vez de año académico. No sabe para qué sirve la casilla de externo. Búsqueda de lista de notificaciones Completada con errores 5s Encuentra las notificaciones en el resumen y no en la campana Explorar lista de Completada 2m20s Hay que indicarle que tiene que buscar 146 notificaciones (búsqueda de notificación de oferta aceptada) con errores su notificación. Comprobar datos del socio Completada sin errores 5s Encuentra sin problemas el enlace. Rellenar formulario de partenariado (completar datos de oferta) Completada sin errores 5s Envía el formulario directamente. Explorar lista de notificaciones (búsqueda de notificación de partenariado creado) Completada sin errores 5s Encuentra la notificación adecuadamente Encontrar listado de partenariados personal Completada sin errores 5s Encuentra el partenariado correctamente. Solo se ha creado un partenariado. Métricas Número de tareas totales 17 Número de tareas completadas sin errores 12 Tasa de tareas completadas sin errores 70,6% Número de tareas completadas con errores 4 Tasa de tareas completadas con errores 23,5% Número de tareas sin completar 1 Tasa de tareas sin completar 5,9% Tiempo total empleado 25m55s Comentarios adicionales (entrevista): ● Echa de menos áreas de conocimiento, dejaría abierta la opción de poder ingresar alguna personalizada. ● Añadir textos de ayuda en los campos. ● Información incorrecta en el partenariado. ● Añadir enlace externo de información adicional. 147 Usuario: Profesora en la Facultad de Informática de la UCM Nivel informático: Alto Nivel ApS: Alto Tarea Estado Tiempo Comentarios Búsqueda de información Completada sin errores 7m30s Encuentra sin problemas la sección. Hay faltas de ortografía y es demasiado denso, no ve bien que no se vean todas las preguntas desde el principio y no le gusta que se abusen de las mayúsculas. Registro Completada con errores 2m Intenta introducir una contraseña de 4 caracteres, cada uno de un tipo y no le deja. Sugiere que el feedback está incompleto porque no le da todas las pistas necesarias para introducir una contraseña correcta. Encuentra bien tanto la universidad como el área de conocimiento de la UNESCO. Cuando se registra, abre la página principal desde abajo y no desde el principio, lo cual no le gusta. Login Completada sin errores 30s No tiene problemas para hacer login. Encontrar listado de ofertas Completada sin errores 5s La encuentra sin problemas. Explorar listado de ofertas Completada con errores 2m Hubiera intentado hacer click en el título de la oferta, y dice que el ojo no guarda consistencia interna en la aplicación para visualizar la oferta. Encontrar botón de crear oferta Completada sin errores 5s Encuentra la opción sin problemas y de forma intuitiva. Rellenar formulario de oferta Completada con errores 2m30s Pone curso en vez de año académico objetivo. No le gusta que cuando envía el formulario no le lleve a la lista de ofertas y le salga otro formulario. Encontrar listado de ofertas personal No completada x Confunde listado de ofertas general con el personal. Le gustaría que estuvieran ordenadas las ofertas de más nueva a más antigua. Encontrar listado de demandas Completada sin errores 5s No tiene problemas para encontrarla. Explorar listado de demandas con filtros Completada sin errores 1m30s No le gusta que en el filtro de necesidad social haya una lista desplegable para elegir varios valores cuando solo se puede elegir uno. 148 Rellenar formulario de partenariado (respalda de demanda) Completada con errores 2m30s Le sale una advertencia de campos obligatorios sin rellenar pero en los campos no sale ningún asterisco en el que indique qué campos son obligatorios. Los errores deberían saltar a nivel de campo y no al final porque le provoca tener que subir y bajar para encontrar los campos que le falta de rellenar. El campo de área de implementación no guarda consistencia interna porque pone área de servicio. Búsqueda de lista de notificaciones Completada sin errores 5s Encuentra la campana de notificaciones. Explorar lista de notificaciones (búsqueda de notificación de oferta aceptada) Completada con errores 15s No encuentra su notificación y hay que indicarle que se está equivocando y debe encontrar la notificación relacionada con su oferta. Comprobar datos del socio Completada sin errores 10s Le gustaría que hubiera alguna forma de volver para atrás dentro de la página. Rellenar formulario de partenariado (completar datos de oferta) Completada sin errores 30s No entiende por qué tiene que completar datos de la oferta si supuestamente ya había rellenado todos los campos necesarios cuando la creó, lo que le frustra bastante. Explorar lista de notificaciones (búsqueda de notificación de partenariado creado) Completada sin errores 5s Encuentra la notificación adecuadamente. Encontrar listado de partenariados personal Completada sin errores 5s Encuentra la lista perfectamente. Solo se ha creado un partenariado correctamente. El partenariado que debería surgir de la respalda de la demanda no se ha creado correctamente porque no aparece. Métricas Número de tareas totales 17 Número de tareas completadas sin errores 11 Tasa de tareas completadas sin errores 64,7% Número de tareas completadas con errores 5 Tasa de tareas completadas con errores 29,4% 149 Número de tareas sin completar 1 Tasa de tareas sin completar 5,9% Tiempo total empleado 19m40s Comentarios adicionales (entrevista): ● Las notificaciones deberían aparecer ordenadas cronológicamente, la fecha y la hora y las que están sin leer y no lo están. Usuario: Empleada en ONG Ongawa Nivel informático: Usuario Nivel ApS: Medio Tarea Estado Tiempo Comentarios Búsqueda de información Completada sin errores 4m45s Encuentra perfectamente el icono de socio comunitario. Se toma su tiempo para leer todo. Registro Completada con errores 6m30s Se mete en Login y no en Registro. Se pierde un poco y hay que indicarle donde está el registro. Intenta poner “_” como caracter especial y no le vale. Hay que indicarle que pruebe otro caracter especial. Tampoco le funciona un punto. Encontrar listado de ofertas Completada con errores 5s Encuentra la lista pero no en la barra de navegación. Explorar listado de ofertas con filtros Completada sin errores 5m10s Se da cuenta de que el contador de ofertas está mal. Entra en una oferta y comienza a leer los datos. Los entiende. Echa en falta la función del estudiante, de la organización y del profesor en la descripción de la oferta. Encontrar opción de crear demanda Completada sin errores 40s Encuentra intuitivamente el botón yéndose a su área personal y entrando en Mis Demandas. Rellenar formulario de demanda Completada con errores 9m30s Observa que se pueden seleccionar varias áreas de implementación de forma intuitiva. Se toma su tiempo para describir la demanda. Se pierde un poco con tantas fechas. Escribe una necesidad social en vez de seleccionarla del desplegable y al mandar el formulario le da error. Se da cuenta de que tiene que seleccionarla. Búsqueda de lista de notificaciones Completada con errores 5s Entra primero en el resumen y las encuentra pero luego observa la 150 campana. Explorar lista de notificaciones (petición aceptada) Completada sin errores 5s La encuentra sin problemas. Se queja de que hay errores de ortografía. Rellenar formulario de partenariado (petición aceptada) Completada con errores 6m10s Le cuesta entender el formulario. Se queja de que pueda modificar campos que no debería tener que tocar. Procede a modificar solo los de la demanda. Prueba a intentar dejar los campos de fecha vacíos pero se da cuenta de que no le deja porque no puede crearlo. Le salta una ventana de error y a continuación una de actualizado correctamente. Explorar lista de notificaciones (búsqueda de notificación demanda respaldada) Completada sin errores 5s Se queja de que el número de notificaciones no aparezca automáticamente. Rellenar formulario de partenariado (demanda respaldada) Completada sin errores 1m10s Observa que todos los campos de la demanda están rellenados correctamente. Encontrar listado de partenariados personal Completada sin errores 5s Solo le aparece un partenariado creado y se da cuenta. Se da cuenta de que hay errores en la información del partenariado. Métricas Número de tareas totales 12 Número de tareas completadas sin errores 7 Tasa de tareas completadas sin errores 58,3% Número de tareas completadas con errores 5 Tasa de tareas completadas con errores 41,7% Número de tareas sin completar 0 Tasa de tareas sin completar 0% Tiempo total empleado 34m20s 151 Comentarios adicionales (entrevista): ● Incluir una biografía opcional en el campo de registro. ● Destaca los filtros como funcionalidad intuitiva. ● Destaca de nuevo que las fechas le resultan confusas. Usuario: Empleada de Servicios Informáticos de la ONCE Nivel informático: Alto Nivel ApS: Bajo Tarea Estado Tiempo Comentarios Búsqueda de información Completada sin errores 5m Además de leer las instrucciones de socio comunitario, lee las de profesores y las de alumnos. Se da cuenta que el logo de la UNED sirve como botón para volver atrás. Registro Completada sin errores 1m45s Introduce bien la contraseña después de que le pidan que introduzca un carácter especial. Encontrar listado de ofertas Completada con errores 5s Encuentra las ofertas en la página principal, no en la barra de navegación. Explorar listado de ofertas con filtros Completada sin errores 1m Prueba con el filtro de innovación pero no hay ninguna. Sigue probando. Deja de probar filtros y le gusta un, por lo que accede a ella. Encontrar opción de crear demanda Completada sin errores 10s Encuentra el botón de crear demanda en la lista de sus demandas. Rellenar formulario de demanda Completada con errores 4m15s Intenta introducir una necesidad social que no está en la lista y deja el campo de requisitos especiales vacío y de titulación. Intenta crear la demanda pero le da error porque la necesidad seleccionada no es correcta y se da cuenta de que es un desplegable. No encuentra ninguna que se ajuste exactamente. Comprueba que se ha creado correctamente en sus demandas. Búsqueda de lista de notificaciones Completada con errores 5s Encuentra la lista en el resumen y no en la campana Explorar lista de notificaciones (petición aceptada) Completada sin errores 5s Encuentra la notificación sin problemas Rellenar Completada 2m30s Entiende perfectamente el formulario y 152 formulario de partenariado (petición aceptada) sin errores rellena todos los campos sin problemas. Explorar lista de notificaciones (búsqueda de notificación demanda respaldada) Completada sin errores 30s Se da cuenta de que la notificación apropiada es la de demanda respaldada. Rellenar formulario de partenariado (demanda respaldada) Completada sin errores 20s Rellena los campos que necesita sin problemas. Encontrar listado de partenariados personal Completada sin errores 5s Encuentra la lista sin problemas y están los dos creados correctamente. Se da cuenta de que la información que aparece es incorrecta. Métricas Número de tareas totales 12 Número de tareas completadas sin errores 9 Tasa de tareas completadas sin errores 75% Número de tareas completadas con errores 3 Tasa de tareas completadas con errores 25% Número de tareas sin completar 0 Tasa de tareas sin completar 0 Tiempo total empleado 15m50s Comentarios adicionales (entrevista): ● No sabe si los datos que se publican son accesibles por todo el mundo o no y que debería haber una explicación explícita sobre el tratamiento de los datos. ● La parte de las fechas le parece un poco liosa, haría en menos pasos el tema de las fechas. No sabe límite coincide con la del fin de periodo o no. Dejaría más abiertos los campos de las fechas del periodo de disponibilidad y de la realización, y el de la realización no lo pondría todavía en esta fase porque es algo que se discute más adelante. Prefiere que la necesidad social te de la posibilidad de meter el valor por lista desplegable predefinida o poner tú el que quieras. ● Le parece lioso un poco del tema de los formularios de partenariado ya que se pide información que no le parece muy bien diferenciado entre socio y profesor, y le parecen demasiado extensos lo que le provoca que rellene campos por rellenar sin entender muy bien para qué sirven. 153