DESARROLLO DE UNA PLATAFORMA LIBRE DE VIDEO INTERACTIVO Y MULTISENSORIAL PARA LA ASIGNATURA DE VIDEO Y TELEVISION

DIGITAL. PROYECTO: PLATEA PLAYER

ANDRES DAVID LIU FONG 2130120

UNIVERSIDAD AUTONOMA DE OCCIDENTE

FACULTAD DE INGENIERIA DEPARTAMENTO DE OPERACIONES Y SISTEMAS

PROGRAMA INGENIERIA MULTIMEDIA SANTIAGO DE CALI

2018

DESARROLLO DE UNA PLATAFORMA LIBRE DE VIDEO INTERACTIVO Y MULTISENSORIAL PARA LA ASIGNATURA DE VIDEO Y TELEVISION

DIGITAL. PROYECTO: PLATEA PLAYER

ANDRES DAVID LIU FONG

Proyecto de grado para optar al título de Ingeniero Multimedia

Director JUAN VICENTE PRADILLA CERÓN

Ingeniero Telemático e Ingeniero de Sistemas

UNIVERSIDAD AUTONOMA DE OCCIDENTE FACULTAD DE INGENIERIA

DEPARTAMENTO DE OPERACIONES Y SISTEMAS PROGRAMA INGENIERIA MULTIMEDIA

SANTIAGO DE CALI 2018

3

NOTA DE ACEPTACIÓN:

Aprobado por el Comité de Grado en cumplimiento de los requisitos exigidos por la Universidad Autónoma de Occidente para optar al título de Ingeniero Multimedia

Andrés Fernando Solano Alegría

Jurado

Leonardo Saavedra Munar

Jurado

Santiago de Cali, 25 de septiembre de 2018

4

CONTENIDO

pág. RESUMEN 13 INTRODUCCIÓN 14 1. DEFINICIÓN DEL PROBLEMA 16 2. JUSTIFICACIÓN 18 3. OBJETIVOS 20 3.1. OBJETIVO GENERAL 20 3.2. OBJETIVOS ESPECÍFICOS 20 4. MARCO REFERENCIAL 21 4.1. MARCO CONCEPTUAL 21 4.1.1. Diseño centrado en el usuario (DCU) 21 4.1.2. Open Source 21 4.1.3. Video interactivo 21 4.1.4. Player/Playback 21 4.1.5. Interacción sensorial 22 4.1.6. Video multisensorial 22 4.1.7. Video social (SocialTV) 22 4.2. MARCO TEÓRICO 22 4.2.1. Leyes de la Gestalt sobre la organización perceptual 23

5

4.2.2. ISO 9241-210:2010 24 4.3. MARCO CONTEXTUAL 26 4.4. MARCO DEL ESTADO ACTUAL 26 4.4.1. Videopath 26 4.4.2. Wirewax 28 4.4.3. RaptMedia 29 4.4.4. H5P 30 4.4.5. Liferay Portal 30 4.4.6. YouPHPTube 31 5. METODOLOGÍA 33 5.1. CLASIFICACIÓN DE LA INVESTIGACIÓN 33 5.2. RECOLECCIÓN DE LA INFORMACIÓN 34 5.2.1. Fuentes de datos y tamaño de la muestra 36 5.2.2. Análisis de la información 36 6. DESARROLLO, RESULTADOS Y DISCUSIÓN 37 6.1. DEFINICIÓN DE USUARIOS, CONTEXTO DE USO Y REQUERIMIENTOS 37 6.1.1. Análisis de la competencia 37 6.1.2. Definición de la audiencia 38 6.1.2.1. Espacios a intervenir 39 6.1.2.2. Stakeholders 39 6.1.2.3. Definición del perfil de usuario y necesidades 40

6

6.1.2.4. Definición del escenario de uso 42 6.1.3. Eventos, interacciones y acciones 44 6.1.4. Requerimientos funcionales 46 6.1.5. Requerimientos no funcionales 52 6.1.6. Historias de usuario 58 6.2. DISEÑO Y PROPUESTA DE SOLUCIÓN 59 6.2.1. Diseño de interfaces gráficas 59 6.2.1.1. Prototipo preliminar del player 59 6.2.1.2. Diseño preliminar de la plataforma social 60 6.2.2. Arquitectura del sistema 62 6.2.2.1. Archivo JSON de interacciones 63 6.2.2.2. JSON: Esquema de shift para interacciones HOT_SPOT 65 6.2.2.3. JSON: Esquema de shift para interacciones WEB_CONTENT 68 6.2.2.4. JSON: Esquema de shift para interacciones INDEX 69 6.2.2.5. JSON: Esquema de shift para interacciones SENSE 69 6.3. DESARROLLO INTEGRAL DEL SISTEMA 71 6.3.1. Software 72 6.3.1.1. Player interactivo 72 6.3.1.2. Plataforma web social 74 6.3.1.3. Servidor 77 6.3.2. Hardware 78 6.3.2.1. Componentes electrónicos para interacciones sensoriales 79 6.3.2.2. Bill of materials (BOM) 82

7

6.3.3. Firmware 85 6.3.4. Modelo prototipo preliminar del objeto físico 86 6.3.5. Modelo de estudio del objeto físico final 88 6.3.6. Concept testing del módulo sensorial 89 6.3.7. Primer modelo prototipo del objeto físico final 90 6.4. VALIDACIÓN Y MEJORAS 91 6.4.1.2. Versión final del modelo prototipo del objeto físico 92 6.4.2. Experimentos formales del player y plataforma web social 94 6.4.2.1. Lista de actividades 94 6.4.2.2. Métricas evaluadas 98 6.4.3. Escala de Usabilidad del Sistema (SUS) 107 6.4.4. Entrevista de satisfacción general post-test 108 6.4.5. Implementación de mejoras al sistema 109 7. CONCLUSIONES 111 7.1. CONTRIBUCIONES E IMPLICACIONES 111 7.2. LIMITACIONES 114 BIBLIOGRAFÍA 116 ANEXOS 120

8

LISTA DE CUADROS

pág. Cuadro 1. Métodos de indagación a usar 34 Cuadro 2. Vistazo general de las alternativas para players interactivos. 38 Cuadro 3. Vistazo general de las alternativas para plataformas 38 Cuadro 4. Descripción del contexto geográfico del usuario 39 Cuadro 5. Lista de eventos e interacciones 44 Cuadro 6. Lista de acciones 46 Cuadro 7. Requerimientos funcionales del sistema 47 Cuadro 8. Requerimientos no funcionales del sistema 52 Cuadro 9. Ejemplo del esquema para historias de usuario 58 Cuadro 10. BOM 82 Cuadro 11. Lista de experimentos formales 95 Cuadro 12. Lista de métricas evaluadas 98 Cuadro 13. Análisis de actividades con error crítico en la primera Iteración 102 Cuadro 14. Tiempos de terminación para las actividades #1 y #5 en la primera iteración 104 Cuadro 15. Referencia de tiempos de terminación para las actividades #1 y #5 con un usuario experimentado 105 Cuadro 16. Resultado del SUS de la primera iteración 107 Cuadro 17. Resultado del SUS de la segunda iteración 108

9

LISTA DE FIGURAS

pág. Figura 1. Gestalt 24 Figura 2. Experiencia de usuario 25 Figura 3. Interfaz del player de Videopath 27 Figura 4. Interfaz del player de Wirewax 28 Figura 5. Interfaz del player de RaptMedia 29 Figura 6. Interfaz del player de H5P 30 Figura 7. Principales componentes de la arquitectura de Liferay Portal. 31 Figura 8. Interfaces desktop y mobile de la página de un video en YouPHPTube 32 Figura 9. Proceso de diseño centrado en el usuario 33 Figura 10. Ficha de la Persona creada 42 Figura 11. Storyboard del escenario de uso 43 Figura 12. Diseño preliminar del player 60 Figura 13. Menú desplegable para elementos adicionales de la interfaz del player 60 Figura 14. Interfaz de la página principal de la plataforma 61 Figura 15. Interfaz de la página de un video de la plataforma 61 Figura 16. Diagrama de despliegue del sistema 62 Figura 17. Esquema del archivo JSON 64 Figura 18. Shift de interacciones HOT_SPOT para tipos POLY y ELLIPSE 66 Figura 19. Shift de interacciones HOT_SPOT para tipo TEXT 67 Figura 20. Shift de interacciones HOT_SPOT para tipo VIDEO 67

10

Figura 21. Shift de interacciones WEB_CONTENT 68 Figura 22. Shift de interacciones INDEX 69 Figura 23. Shift de interacciones SENSE 70 Figura 24. Transform de interacciones SENSE para tipo LIGHT 70 Figura 25. Transform de interacciones SENSE para tipo TEMP 71 Figura 26. Diseño final del player usado como primer prototipo para pruebas. 73 Figura 27. Estado on hover de los controles 74 Figura 28. Interfaz original de carga de un video 76 Figura 29. Interfaz modificada para permitir asociar un archivo JSON con el video cargado 76 Figura 30. Nuevo campo json en la tabla “videos” del MER de la base de datos 77 Figura 31. Diagrama de caja negra del módulo sensorial 78 Figura 32. Modelo de ventilador usado 79 Figura 33. Esquema de funcionamiento para la interacción de agua 80 Figura 34. Humidificador ultrasónico para el módulo de humo 80 Figura 35. Cinta de LEDs usada para la interacción de luz 81 Figura 36. Distribución de la estructura del módulo de temperatura 81 Figura 37. Diagrama de caja transparente del módulo sensorial 84 Figura 38. Boceto del prototipo preliminar del objeto físico 87 Figura 39. Objeto físico preliminar 87 Figura 40. Boceto del modelo de estudio del objeto físico 88 Figura 41. Modelo de estudio del objeto físico 89

11

Figura 42. Modelo prototipo del objeto físico final 91 Figura 43. Proceso de evaluación con usuarios 92 Figura 44. Principales modificaciones al objeto físico 93 Figura 45. Versión final del objeto físico 93 Figura 46. Ejemplo del entorno de desarrollo de los experimentos formales a través de la aplicación lookback 100 Figura 47. Resultados de actividades completadas en la primera Iteración 101 Figura 48. Porcentajes de éxito total versus error crítico en la primera iteración 101 Figura 49. Resultados de actividades completadas en la segunda Iteración 106 Figura 50. Porcentajes de éxito total versus error crítico en la segunda iteración 106 Figura 51. Botón para cargar un video 109 Figura 52. Botones laterales con mayor opacidad 110 Figura 53. Nuevos íconos preliminares para cambiar la velocidad de reproducción del video 110

12

LISTA DE ANEXOS

pág. Anexo A. Historias de usuario 120 Anexo B. Formato empleado para aplicar el SUS 124 Anexo C. Resultados de la encuesta de caracterización de usuarios y contexto 125 Anexo D. Otros resultados de encuestas 126 Anexo E. Encuesta de caracterización de usuarios y contexto 127 Anexo F. MER de la base de datos 132 Anexo G. Guion de entrevista post-test 133

13

RESUMEN

Este trabajo describe el proceso seguido para diseñar y desarrollar una plataforma web que permite desplegar y compartir socialmente videos interactivos multisensoriales cuyas interacciones se definen en un archivo JSON, orientada a mejorar la calidad de los proyectos presentados por los estudiantes de la asignatura de Video y Televisión Digital de la Universidad Autónoma de Occidente.

A partir de un estudio inicial al público objetivo mediante encuestas (𝑁𝑒𝑛𝑐 = 19), se determinaron aspectos demográficos, psicográficos y conductuales que permitieron definir sus características y contexto en la problemática; y de manera consecuente formalizar los requerimientos funcionales y no funcionales del sistema. Posterior al desarrollo de un primer modelo prototipo tanto a nivel virtual como físico, se diseñaron pruebas de validación consistentes en un concept testing

(𝑁𝑐𝑝𝑡 = 5) con un modelo de estudio del módulo sensorial, y una secuencia de

experimentos formales, seguidos por la aplicación de una escala de usabilidad del sistema (SUS), y una entrevista final (𝑁𝑒𝑥𝑝 = 10), contando con la participación de

usuarios representativos del público objetivo, y llevadas a cabo en el contexto geográfico de la propuesta de solución. Esta secuencia se realizó en dos iteraciones con muestras iguales, y con base en el feedback proveído para implementar mejoras de requerimientos y usabilidad. El resultado del SUS fue de 74 para la primera iteración, y de 76.5 en la segunda. Aunque los resultados pueden ser considerados buenos al sobrepasar los 68 puntos, definidos como el promedio; el incremento entre ambas iteraciones no fue muy significativo, posiblemente debido a factores de estilo. Finalmente, la plataforma se ha puesto a disposición de la comunidad para su uso y adaptación de forma libre y gratuita. Adicionalmente, durante el semestre en curso se comienza el uso de la plataforma dentro de la asignatura de Video y Televisión Digital. Palabras clave: Video interactivo; video multisensorial; video social; plataforma de video; open source.

14

INTRODUCCIÓN

El término video interactivo ha variado en gran medida durante las últimas cuatro décadas, transformando el concepto original del video como una simple secuencia lineal de fotogramas, al integrar diferentes grados y tipos de interacción. Es posible denotar esta evolución haciendo una comparación desde el control sencillo del playback, pasando por la interactividad por medio de elementos sobrepuestos (hotspots, picture-in-picture, anotaciones, etc.), hoy considerada como básica, hasta llegar al desarrollo de sistemas más complejos que integran soluciones de procesamiento digital de imágenes en tiempo real, e-commerce, quizzes, plataformas web, y APIs para desarrolladores. El constante progreso alrededor de esta tecnología da cuenta de su efectividad en diversos ámbitos educativos, comerciales, publicitarios, de entretenimiento, entre otros, comprobada en estudios pasados, y resultantes de la implementación de este tipo de videos como reemplazo o adición a los procesos tradicionales propios de cada uno, generando una necesidad por herramientas que faciliten su desarrollo en diferentes niveles de complejidad. En este sentido, durante los últimos años se han desarrollado diferentes plataformas que buscan proporcionar este tipo de medios orientados a la creación, el despliegue y la publicación de videos interactivos, ofreciendo diversas características enfocadas a diferentes nichos de mercado, lo cual supone que la mayoría de las tecnologías actualmente disponibles no son gratuitas ni de libre acceso continuo. Además, los diferentes tipos de contenido interactivo disponibles por estas plataformas se limitan al entorno digital y no se aprovecha el uso de otras tecnologías relativamente emergentes que integran el contexto físico del usuario, ofreciendo también medios de interacción innovadores que, aunque en detrimento de factores como costo y acceso, podrían incrementar la participación de sus usuarios, aportando a la consecución del objetivo general para el que fueron diseñados e implementados. En torno a la Ingeniería Multimedia, el desarrollo y uso de videos interactivos está, generalmente, limitado a la asignatura de Video y Televisión Digital (V&TVD) al ser parte fundamental del curso. Sin embargo, este medio de comunicación puede llegar a ser de utilidad en el contexto de proyectos de otras materias gracias a su amplio campo de implementación y posibilidad de integración en sistemas multimedia que incluyan otras tecnologías; y cuyas únicas limitantes,

15

sobrepasando las dificultades técnicas, son sólo las capacidades creativas y habilidades estéticas en la creación del contenido multimedia presentado. Es entonces evidente el contraste entre las oportunidades que ofrece el video interactivo versus la factibilidad para desarrollarlos con calidad. Así, con el desarrollo de este trabajo se pretende dar consecución a dos aspectos principales: brindar a los estudiantes de V&TVD un sistema gratuito y completo que les permita desplegar videos interactivos; y la expansión del campo de videos interactivos a través de la creación de una plataforma web social y libre similar a YouTube para compartirlos, y la adición de un nuevo tipo de interactividad en el entorno real del usuario mediante el desarrollo de un sistema de computación física para interacciones sensoriales. De esta forma, se espera generar una referencia para futuras producciones que hagan uso de videos interactivos, específicamente alrededor de estas características.

16

1. DEFINICIÓN DEL PROBLEMA

La calidad actual de las soluciones presentadas por los estudiantes para proyectos y problemas de la asignatura de Video y Televisión Digital que involucren la creación y visualización de videos interactivos no alcanza el nivel profesional esperado dentro del alcance de la asignatura y las capacidades adquiridas por los estudiantes.

Esta situación se debe a que en la actualidad es necesario hacer uso de un número limitado de plataformas que cuentan con una versión gratuita o un periodo de prueba para crear los videos interactivos, además de que ninguna implementa la reproducción de videos con interacción multisensorial. Esto implica limitaciones visuales como la superposición constante de marcas de agua, aparición de avisos publicitarios, o la presencia de pantallas promocionales de la plataforma previas al video creado; y/o limitaciones temporales que fijan su duracion maxima. Para algunos proyectos que requieren de videos de larga duracion, los estudiantes deben recurrir a dos opciones habituales:

Enganar al servicio creando varias cuentas gratuitas. Este proceso puede incrementar el tiempo de desarrollo del proyecto que, ademas, debe ser presentado por partes pues el video, entendido como el contenido, no puede ser descargado ni usado sin el player especial para reproducirlo.

Emplear varias plataformas que ofrezcan caracteristicas similares. Puede resultar mas complejo pues no existen muchas opciones gratuitas. Sin embargo, si los requerimientos del proyecto ameritan el uso de una caracteristica presente en diferentes plataformas, se hace necesario.

Por otra parte, la alternativa no comercial es desarrollar por si mismos las funcionalidades del sistema. Lo cual, dependiendo de la complejidad del proyecto o problema, puede incrementar el tiempo para completarlo al depender de las capacidades de los estudiantes, y en caso de desconocer las herramientas para el desarrollo, se debe invertir un tiempo considerable en el proceso de aprendizaje. Contrastando con el tiempo de trabajo independiente de 2 horas por 1 hora de clase estipulado por la Universidad, se evidencia una carencia de horas formales orientadas al progreso del proyecto.

Adicionalmente, la mayoría de las plataformas en línea para videos interactivos que existen en la actualidad acarrean un costo monetario que no es asequible

17

para un estudiante enmarcado en el contexto de un proyecto de clase. Ademas, estos costos deben ser pagados bajo un modelo de suscripcion, llegando a variar entre USD $100/mes y $5000/mes dentro de las opciones mas economicas que son completas.1

Estos altos costos son consecuentes a que el publico objetivo de este tipo de plataformas son empresas publicitarias, de entretenimiento o de soluciones educativas que poseen un alcance masivo pues se verian beneficiadas en gran medida a traves de una probabilidad de incremento del 66% en la participacion de sus usuarios, del 44% en el tiempo de visualizacion de su contenido, y del 25% en conversiones,2 y por lo tanto se asume que cuentan con el dinero para invertir.

Asi, las limitaciones tecnicas son entonces el principal impedimento para el desarrollo de proyectos de buena calidad, ya sea por falta de conocimientos propios y tiempo para la programacion, o por falta de recursos para la adquisicion de una herramienta comercial.

De seguir asi, el problema puede conducir a corto plazo a una reduccion en el desempeno educativo a nivel funcional de los estudiantes a consecuencia de las bajas calificaciones recibidas, ademas de las consecuencias variadas de caracter economico, familiar, personal y emocional en el contexto de cada uno; a mediano plazo a una reduccion en el interes general por el area del conocimiento alrededor de videos interactivos, y a largo plazo a una falencia en estas aptitudes tecnicas para todos los estudiantes de la carrera.

Por tanto, en torno a la problematica descrita, se ha identificado la oportunidad de intervenirla dando respuesta a la pregunta: ¿Que mecanismo se puede utilizar para desarrollar proyectos de buena calidad con videos interactivos en la asignatura de Video y Television Digital?

El proyecto donde se enmarca este trabajo se ha denominado Platea, haciendo alusion a la relacion entre el usuario y la tematica tratada. _______________________ 1 Wirewax. Choose The Wirewax Offering That Works For You: You can even trial our Professional package free for 14 days. [en linea]. Wirewax.com. (2017). [Consultado: 13 de octubre de 2017]. Disponible en Internet: https://www.wirewax.com/pricing 2 Demand Metric. Interactive Video: Defining & Measuring Performance [diapositivas]. Brightcove.com. (Noviembre de 2015). [Consultado: 13 de octubre de 2017]. Disponible en Internet: http://files.brightcove.com/bc-demandmetric-interactive-video-benchmark-report.pdf

18

2. JUSTIFICACIÓN

La Ingenieria Multimedia, entendida como “una rama de la ingenieria que busca comprender los principios teóricos y prácticos asociados con la construcción de sistemas computacionales que incorporen la creación, el análisis, el procesamiento, la composición, la presentación, la distribución, la administración, el diseno y la representacion de contenido multimedia”,3 representa un campo de estudio ideal para las temáticas relacionadas con videos interactivos, existiendo un especial interés para este proyecto alrededor de los procesos de procesamiento, presentación, y distribución de los mismos. Explorar estos puntos implicaría un avance en la demostración de su creciente influencia en los roles tanto de medio de convergencia multimediática, como de contenido multimedia en sí mismo. El estudio realizado en 2015 por DEMAND METRIC a 515 profesionales del mercadeo y la publicidad muestra que el 52% (~267) considera que la importancia futura del video interactivo como un tipo de contenido será más importante, y el 16% (~82) considera que será mucho más importante, mientras que sólo el 2% (~10) considera que se volverá menos importante.4

Es entonces posible suponer que durante los próximos años la complejidad de las experiencias con videos interactivos incremente y sea necesaria la implementación de nuevos niveles de interactividad mayores al desarrollado. Así, la demanda por ingenieros de multimedia que conozcan del tema y posean las habilidades técnicas para desarrollar experiencias con videos interactivos también crecerá proporcionalmente. En este sentido, el desarrollo de una plataforma de código libre, acceso gratuito y completa, entendido como la disponibilidad de desplegar interacciones digitales comunes (sobreposición de hotspots, contenido web, videos e imágenes); para la visualización y publicación de videos interactivos y multisensoriales representaría una aproximación original a un sistema con estas características, y podría servir como una base tanto para el estudio o uso directo de otros estudiantes, como para el desarrollo de nuevos proyectos enfocados a su mejoría como plataforma o a la extensión de los servicios que integre. _______________________ 3 Universidad Militar Nueva Granada. Ingeniería en Multimedia [en línea]. Umng.edu.co. [Consultado: 14 de octubre de 2017]. Disponible en Internet: http://www.umng.edu.co/web/guest/programas-academicos/facultad-ingenieria/pregrados/ingenieria-multimedia 4 Demand Metric. Interactive Video: Defining & Measuring Performance [diapositivas]. Brightcove.com. (Noviembre de 2015). [Consultado: 13 de octubre de 2017]. Disponible en Internet: http://files.brightcove.com/bc-demandmetric-interactive-video-benchmark-report.pdf

19

Asimismo, mediante la gratuidad y flexibilidad de esta plataforma basada y construida con herramientas open source, los estudiantes sobrepasarían las limitaciones monetarias y técnicas, y sus consecuencias académicas y aptitudinales actuales, pues ya no tendrían que pagar ni desarrollar por sí mismos. Finalmente, el rango de aplicaciones en las que se podría implementar el proyecto trasciende el ámbito educativo como un objeto de apoyo al proceso de aprendizaje, pudiendo llegar a integrarse como una solución completa de e-learning, y principalmente en campos como la publicidad, marketing, y entretenimiento a través de soluciones como generación de leads, incremento de audiencias, catálogo de productos y analítica de usuarios, entre otras.5

_______________________ 5 Demand Metric. Interactive Video: Defining & Measuring Performance [diapositivas]. Brightcove.com. (Noviembre de 2015). [Consultado: 13 de octubre de 2017]. Disponible en Internet: http://files.brightcove.com/bc-demandmetric-interactive-video-benchmark-report.pdf

20

3. OBJETIVOS

3.1. OBJETIVO GENERAL Desarrollar una plataforma de Video y Televisión Digital que permita a los estudiantes de Ingeniería Multimedia que cursan esta asignatura la inclusión de interactividad estándar y multisensorial en sus videos. 3.2. OBJETIVOS ESPECÍFICOS

● Identificar los requerimientos funcionales y no funcionales de la plataforma PlateaPlayer con base en las necesidades de los usuarios y los requisitos de la asignatura de Video y Televisión Digital.

● Diseñar la arquitectura hardware y software de la plataforma de video interactivo.

● Implementar los módulos de la arquitectura hardware y software necesarios para cumplir con los requerimientos.

● Evaluar la implementación con los usuarios de la plataforma.

21

4. MARCO REFERENCIAL

4.1. MARCO CONCEPTUAL 4.1.1. Diseño centrado en el usuario (DCU). Es una metodología que define las fases que deben llevarse a cabo durante el proceso de diseño y desarrollo del ciclo de vida de un producto, enfocándose en adquirir un entendimiento profundo sobre quién lo usará.6 La norma ISO 9241-210:2010 lo estandariza definiendo 4 etapas en un proceso iterativo. Éstas son: especificar el contexto de uso, especificar requerimientos, producir soluciones de diseño, y evaluarlas. 4.1.2. Open Source. Hace referencia a software que respeta las llamadas 4 libertades. Esto es: puede ser accedido, usado, alterado, y compartido (modificado o no) libremente por cualquiera. Está escrito por muchos contribuidores, y es distribuido bajo licencias que cumplen con la Definición de Open Source.7, 8

4.1.3. Video interactivo. A pesar de que no existe un consenso formal alrededor del término, es posible definirlo a partir de los servicios que brinda, pudiéndose interpretar en términos de: caminos o branching, experiencia interactiva, click dentro de un video, botones clickeables, y como una combinación de todos.9

4.1.4. Player/Playback. Un player es un software para reproducir archivos multimedia como videos, imágenes, y audio; siendo el enfoque en este proyecto el video. Implementan una interfaz gráfica a través de la cual se controlan las características de su reproducción. El conjunto de estas características y su control se denomina playback. _______________________ 6 U.S. Department of Health & Human Services. User-Centered Design Basics [en línea]. Usability.gov. [Consultado: 15 de octubre de 2017]. Disponible en Internet: https://www.usability.gov/what-and-why/user-centered-design.html 7 Open Source Initiative. Basics of Open Source: What is “Open Source” software? [en línea]. Opensource.com. [Consultado: 15 de octubre de 2017]. Disponible en Internet: https://opensource.org/faq#osd 8 Open Source Initiative. The Open Source Definition [en línea]. Opensource.com. [Consultado: 15 de octubre de 2017]. Disponible en Internet: https://opensource.org/osd 9 Demand Metric. Interactive Video: Defining & Measuring Performance [diapositivas]. Brightcove.com. (Noviembre de 2015). [Consultado: 13 de octubre de 2017]. Disponible en Internet: http://files.brightcove.com/bc-demandmetric-interactive-video-benchmark-report.pdf

22

4.1.5. Interacción sensorial. Es la respuesta de los diferentes sistemas del cuerpo ante la detección de estímulos provenientes del exterior.10 En el contexto de videos interactivos se hace referencia a la excitación controlada de estos sentidos mediante la sincronización entre el contenido presentado y la modificación de los factores ambientales del entorno del usuario, con el objetivo de generar una mayor inmersión. 4.1.6. Video multisensorial. Lo multisensorial se define como aquello que se relaciona o involucra diversos sentidos fisiológicos.11 Un video multisensorial hace entonces referencia a un video que implementa varias interacciones sensoriales, entendidas desde el concepto anteriormente descrito. 4.1.7. Video social (SocialTV). Se entiende como la combinación entre las redes sociales y la televisión tanto tradicional como interactiva dependiendo de las herramientas y canales de retorno disponibles, fomentando la participación con el contenido y la interacción entre espectadores geográficamente distantes.12 4.2. MARCO TEÓRICO El estudio alrededor de la temática de videos interactivos con aplicaciones digitales modernas más allá del control del playback es relativamente reciente.13 Durante la última década se han publicado más de 70 papers que involucran la creación o manipulación de videos interactivos, más no se ha formalizado un consenso común acerca de la teoría detrás del tema, existiendo diversas descripciones para definir el término video interactivo con base en la experiencia de cada individuo.14 _______________________ 10 Carnegie Mellon University Open Learning Initiative. Introduction to Psychology (Open + Free): Module 9 / Sensation and Perception [en línea]. Oli.cmu.edu. [Consultado: 15 de octubre de 2017]. Disponible en Internet: https://oli.cmu.edu/jcourse/workbook/activity/page?context=df3e70ea0a0001dc759a394265a80f9a 11 Merriam-Webster. Multisensory [en línea]. Merrian-webster.com. [Consultado: 15 de octubre de 2017]. Disponible en Internet: https://www.merriam-webster.com/dictionary/multisensory 12 Isdi. Social TV como herramienta de marketing digital [en línea]. Isdi.education. [Consultado: 21 de julio de 2018]. Disponible en Internet: https://www.isdi.education/es/isdigital-now/social-tv-como-herramienta-de-marketing-digital 13 SCHOEFFMANN, Klaus; HUDELIST, Marco A. y HUBER, Jochen. Video Interaction Tools: A Survey of Recent Work [en línea]. En: ACM Computing Surveys. (Septiembre de 2015). [Consultado: 14 de octubre de 2017]. Disponible en Internet: https://www.researchgate.net/profile/Klaus_Schoeffmann2/publication/282468629_Video_Interaction_Tools/links/5744618f08aea45ee850cde5/Video-Interaction-Tools.pdf 14 Demand Metric. Interactive Video: Defining & Measuring Performance [diapositivas]. Brightcove.com. (Noviembre de 2015). [Consultado: 13 de octubre de 2017]. Disponible en Internet: http://files.brightcove.com/bc-demandmetric-interactive-video-benchmark-report.pdf

23

Así, en los siguientes apartados se exponen una teoría visual clásica y una serie de lineamientos a tenerse en cuenta para el diseño de sistemas interactivos, cuya exploración se enmarca dentro de su implementación para el proceso de diseño y desarrollo de la interfaz gráfica de usuario para el player de este proyecto y el dispositivo para interacciones sensoriales. 4.2.1. Leyes de la Gestalt sobre la organización perceptual. Fundada entre las décadas de los 30s y 40s por Max Wertheimer, Wolfgang Köhler y Kurt Koffka, la psicología de la Gestalt intenta comprender fenómenos psicológicos visuales mediante su percepción como entidades completas y estructuradas en vez de como una suma de sus partes constitutivas. Esta teoría sumariza sus conceptos a través de 8 leyes que se describen a continuación.15

● Ley de proximidad: cuando se percibe una colección de objetos, aquellos que se encuentren unos más cerca de otros serán asociados como parte de un mismo grupo. ● Ley de similitud: define que los elementos serán perceptualmente agrupados si son similares entre sí, ya sea por características de color, forma o estructura. ● Ley de simetría: declara que aquellos objetos que presenten una simetría, sin importar cuán distantes estén entre sí, establecen un grupo perceptivo conformando una idea de completitud. ● Ley de continuidad: la continuidad ocurre cuando se establece un patrón de movimiento en el enfoque de la percepción, de tal forma que la vista se ve obligada a seguirlo desde un elemento hacia otro. ● Ley de cierre: se establece cuando un objeto está incompleto o un espacio no está completamente cerrado. Si hay suficiente información evidente de la forma original, el elemento se puede percibir como un todo, completando la información faltante. ● Ley de encierre: establece que aquellos elementos que se encierren dentro de un elemento común son percibidos como un grupo. Generalmente se implementa mediante la utilización de bordes, colores de fondo y sombras. ● Ley de conexión: aquellos objetos que se encuentran unidos entre sí mediante algún elemento conector común son percibidos como relacionados o que juntos pertenecen a un grupo. ● Ley de figura y fondo: ciertos objetos toman un rol más prominente mientras que otros ceden su espacio hacia el fondo de manera natural. Generalmente se emplean técnicas mediante el color y el espacio negativo, aplicándose en conjunto con la ley de cierre. _______________________ 15 SOEGAARD, Mads. Gestalt principles of form perception [en línea]. Interaction-design.org. [Consultado: 14 de octubre de 2017]. Disponible en Internet: https://www.interaction-design.org/literature/book/the-glossary-of-human-computer-interaction/gestalt-principles-of-form-perception

24

La figura 1 muestra una condensación de estas leyes en una sola imagen para facilitar su distinción. Figura 1. Gestalt

Fuente: BRITO, Valessio. Gestalt [imagen]. Wikimedia Commons. [Consultado: 15 de octubre de 2017]. Disponible en Internet: https://commons.wikimedia.org/wiki/File:Gestalt.svg

5.2.2. ISO 9241-210:2010. Provee requerimientos para principios y actividades centradas en el usuario a lo largo del ciclo de vida de sistemas interactivos basados en computadoras. Su contenido se enfoca en factores humanos y problemas ergonómicos de manera que se comprenda su relevancia e importancia para el proceso de diseño como un todo, delineando las pautas a seguir, mas no llega a adentrarse mucho en ningún punto.16 En este sentido, el estándar describe 6 principios clave a implementarse.17

● El diseño se basa en un entendimiento explícito de los usuarios, tareas y entornos, permitiendo comprender el problema a profundidad. ● Los usuarios están involucrados a lo largo de los procesos de diseño y desarrollo, desde artefactos preliminares hasta el producto final. ● El diseño se dirige y es refinado mediante una evaluación centrada en el usuario. Así, múltiples métodos de evaluación son requeridos. ● El proceso es iterativo como base para el descubrimiento de mejoras, a través del feedback recibido durante las pruebas de usuario. ● El diseño se enfoca en toda la experiencia de usuario, expandiendo la definición mas allá del antiguo estándar ISO 13407:1999. _______________________ 16 ISO/TC 159/SC 4. Human-centred design for interactive systems. En: ISO 9241-210:2010. 1 ed. p. 6. 17 TRAVIS, David. ISO 13407 is dead. Long live ISO 9241-210! [en línea]. Userfocus.co.uk. (06 de junio de 2011). [Consultado: 14 de octubre de 2017]. Disponible en Internet: http://www.userfocus.co.uk/articles/iso-13407-is-dead.html

25

● El equipo encargado del diseño incluye perspectivas y habilidades multidisciplinarias para asegurar un amplio rango de vistas.

Igualmente, se definen 4 etapas iterativas que corresponden al proceso de diseño y desarrollo centrado en el usuario. Así pues, se formaliza la definición del concepto paraguas experiencia de usuario como “las percepciones y respuestas de una persona, resultantes del uso y/o uso anticipado de un producto, sistema o servicio”.16 Este proceso a través del cual dichas percepciones y respuestas se producen desde la utilidad que el usuario obtiene de su uso, seguido de la facilidad para manipularlos, y la inclinación a querer usarlos, concluyen con la experiencia de usuario (UX) en conjunto adquirida del producto, sistema o servicio tratado. Así, es posible representarlo visualmente a través de la figura 2. Figura 2. Experiencia de usuario

Fuente: nnGroup. User Experience [imagen]. nnGroup Conference Amsterdam. (2008). [Consultado: 14 de octubre de 2017]. Disponible en Internet: http://neospot.se/wordpress/wp-content/uploads/usability-vs-user-experience.jpg

Las leyes y principios clave presentados son aplicables independientemente de la línea visual que se decida implementar pues hacen referencia a la funcionalidad y no a la forma del estilo o estética, la cual será determinada a partir de un proceso de indagación a los usuarios del sistema.

26

4.3. MARCO CONTEXTUAL El alcance inicial del proyecto está enmarcado en la asignatura de Video y Television Digital de la UAO, cuyo objetivo se define como “comprender los conceptos y teorías asociadas al procesamiento digital de video. Reconocer los diferentes parámetros y características fundamentales y aplicaciones de los equipos de video, así como también, estudiar las particularidades del video y la TV digital.”18 Su formato de programa contempla el desarrollo de proyectos enfocados a la creación de videos interactivos durante el primer módulo, pero su aplicación es recurrente durante los demás como tecnología de soporte. Se identificó que los estudiantes pertenecen a los estratos socioeconómicos 3 y 4, y cursan semestres superiores a 8º, lo cual implica que poseen conocimientos técnicos al menos superiores a los básicos. Asimismo, consideran que las temáticas abordadas representan un punto importante para el desarrollo profesional y, de manera general, están satisfechos con el trabajo alcanzado. 4.4. MARCO DEL ESTADO ACTUAL Existen diversas plataformas en línea para la creación y visualización de videos interactivos que se asemejan en cuanto a la integración de los mismos tipos de interacciones, contenidos básicos, analítica ofrecida, y adaptación para dispositivos móviles. Igualmente, existen algunos servicios que facilitan la creación de plataformas de compartición de videos que implementan integraciones sociales a diferentes niveles. A continuación, se presentan algunos de estos sistemas. 4.4.1. Videopath. Permite a cualquier usuario crear videos interactivos sin necesidad de escribir código o realizar implementaciones técnicas. Despliega páginas web, texto, fotos y videos como contenido interactivo; y Facebook, Twitter, Google Plus y e-mail como plataforma social. El almacenamiento de los videos puede integrarse con servicios de terceros como YouTube, Vimeo, Wistia, entre otros, o directamente con su servicio de hosting.19

_______________________ 18 Universidad Autónoma de Occidente. Video y Televisión Digital [en línea]. Ingenieria.uao.edu.co. [Consultado: 15 de octubre de 2017]. Disponible en Internet: http://ingenieria.uao.edu.co/multimedia/videoTV.html 19 Videopath. Our Product [en línea]. Videopath.com. 2016. [Consultado: 13 de octubre de 2017]. Disponible en Internet: https://videopath.com/product/

27

El servicio se presta a través de 3 tipos de suscripciones: Free, Professional, y Enterprise. La versión Free (gratuita) sólo permite integrar videos almacenados en la plataforma de YouTube, sobrepone una marca de agua a los videos, y sólo permite desplegar interacciones básicas tipo hotspot, contenido web embebido, texto y video. Las otras dos versiones, de $399/mes USD y con base en las necesidades, respectivamente, permiten desplegar más tipos de interactividades.20 La figura 3 presenta la interfaz del player. Figura 3. Interfaz del player de Videopath

Fuente: Videopath UG. Interfaz del player de Videopath [imagen]. Videopath. [Consultado: 13 de octubre de 2017]. Disponible en Internet: https://videopath.com/ Lo particular de esta plataforma yace en su relación calidad-precio pues incluso en su versión gratuita hace una buena implementación de las interacciones básicas que son más usadas por los usuarios.21 Sin embargo, no permite una personalización visual completa puesto que ni la interfaz, ni el despliegue de los contenidos, ni la apariencia de los contenidos mismos son modificables más allá de ajustes tipográficos menores y su posicionamiento. Con base en esto, la plataforma propuesta incrementaría las formas para customizar las características de las diferentes interacciones tanto digitales como sensoriales. _______________________ 20 Videopath. Plans [en línea]. Videopath.com. (2016). [Consultado: 13 de octubre de 2017]. Disponible en Internet: https://videopath.com/plans/ 21 SCHOEFFMANN, Klaus; HUDELIST, Marco A. y HUBER, Jochen. Video Interaction Tools: A Survey of Recent Work [en línea]. Op. cit. Disponible en Internet: https://www.researchgate.net/profile/Klaus_Schoeffmann2/publication/282468629_Video_Interaction_Tools/links/5744618f08aea45ee850cde5/Video-Interaction-Tools.pdf

28

4.4.2. Wirewax. Permite integrar interactividad a varios niveles, es decir, un elemento interactivo puede ser utilizado como trigger de otro. También despliega interactividad avanzada como carros de compra, video en 360º, sincronización, cambio de cámara, reproducción paralela, y vinculación a otros videos.22 Posee un plan gratuito para usos no comerciales que está limitado a videos de máximo 10 minutos, ofreciendo sólo las interacciones básicas; y planes pagos que van desde USD $100/mes hasta $5000/mes que adicionan gradualmente las demás interacciones avanzadas y provee otros servicios como bloqueo de la reproducción por dominios y geolocalización, protección con contraseñas, métricas y analíticas más avanzadas, entre otros.23 La figura 4 presenta la interfaz del player. Figura 4. Interfaz del player de Wirewax

Fuente: WIREWAX. Interfaz del player de Wirewax [imagen]. Examples. [Consultado: 13 de octubre de 2017]. Disponible en Internet: https://www.wirewax.com/examples/ La principal característica de la plataforma es la implementación de técnicas de procesamiento digital de imágenes para el reconocimiento y seguimiento (motion tracking) automático de personas y objetos de interés, para su posterior uso como hotspot. Asimismo, el código de cada hotspot puede ser modificado por usuarios avanzados para extender y personalizar su funcionalidad. Teniendo en cuenta que los usuarios del proyecto son estudiantes de semestres avanzados, implementar esta flexibilidad podría resultar beneficiosa para el proyecto. En cuanto a su interfaz, a diferencia de Videopath, es más sencilla y no obstruye tanto el contenido del video, disminuyendo las distracciones y aumentando el engagement del usuario sin afectar su funcionalidad.24 Así, la estética general para el player del proyecto podría seguir la misma línea. _______________________ 22, 23 Wirewax. Interactive video [en línea]. Wirewax.com. (2017). [Consultado: 13 de octubre de 2017]. Disponible en Internet: https://www.wirewax.com/what-is-this/ 24 MEYER, Kate. The Characteristics of Minimalism in Web Design [en línea]. Nngroup.com. (12 de julio de 2015). [Consultado: 13 de octubre de 2017]. Disponible en Internet: https://www.nngroup.com/articles/characteristics-minimalism/

29

4.4.3. RaptMedia. También incluye todas las interacciones básicas, pero se enfoca en la creación de experiencias creativas a través de la vinculación de varios videos mediante hotspots.25 Su público objetivo no son individuos sino empresas de mercadeo, publicidad, entretenimiento y de tecnología, pues no cuenta con una versión gratuita sino con un período de prueba y costos dependiendo del uso de cada cliente. El factor diferenciador de este servicio consiste en la implementación de una API del lado del cliente que le permite a usuarios desarrolladores establecer una comunicación entre el player y la página que lo contenga, posibilitando la creación de nuevos medios de interacción específicos para cada solución en donde se integre. Esta flexibilidad es fundamental para el público objetivo pues así el player del proyecto podría funcionar como un plugin y no estar ligado a ninguna plataforma social o de visualización. La figura 5 presenta la interfaz del player. Figura 5. Interfaz del player de RaptMedia

Fuente: RaptMedia. Interfaz del player de RaptMedia [imagen]. Customers. [Consultado: 13 de octubre de 2017]. Disponible en Internet: http://www.raptmedia.com/customers/ Por otro lado, respecto a la interfaz implementada, los controles de playback están constantemente ocultos hasta ser accionados mediante un click, pausando la reproducción si se desea controlar el playback. Esto entorpece el proceso de un usuario que quiera controlarla rápidamente. Además, se dificulta modificar el tiempo de reproducción pues la barra de progreso es pequeña y no existen botones para controlar la velocidad. Desde el punto de vista de un usuario es parte de su modelo mental esperar que este tipo de controles sean fácilmente encontrables y accesibles.26 Es entonces importante para el proyecto que el modelo mental del usuario se alinee al modelo conceptual del player a través de su interfaz.27

_______________________ 25 RaptMedia. Product [en línea]. Raptmedia.com. [Consultado: 13 de octubre de 2017]. Disponible en Internet: http://www.raptmedia.com/product/ 26 WALKER, Jim. et al. Media player [en línea]. Docs.microsoft.com. (19 de mayo de 2017). [Consultado: 13 de octubre de 2017]. Disponible en Internet: https://docs.microsoft.com/en-us/windows/uwp/controls-and-patterns/media-playback 27 GRANOLLERS, Toni. Modelo Mental y Modelo Conceptual [en línea]. Grihotools.udl.cat. [Consultado: 13 de octubre de 2017]. Disponible en Internet: http://www.grihotools.udl.cat/mpiua/fases-mpiua/diseno/modelo-mental-y-modelo-conceptual/

30

4.4.4. H5P. Plataforma para videos interactivos que, al igual que los servicios descritos anteriormente, integra las interacciones básicas, pero se enfoca en el sector educativo a través de la implementación de diferentes tipos de interacciones de tipo quiz como: completar la frase, pregunta con opción múltiple, drag and drop, entre otras. Se integra con Wordpress, Moodle y Drupal.28

Su tecnología es open source, lo que la hace no sólo accesible a individuos, sino especialmente atractiva para desarrolladores. En este sentido, una vez más aludiendo al público objetivo, las tecnologías empleadas en el proyecto deberían ser libres para facilitar la manipulación del código fuente del proyecto. Del mismo modo, analizar la implementación del plugin para Moodle podría servir de base para crear una integración similar para el proyecto pues sería de utilidad para otros cursos de la Universidad que aún se apoyen de Moodle en vez de Google Classroom. La figura 6 presenta la interfaz del player. Figura 6. Interfaz del player de H5P

Fuente: Joubel. Interfaz del player de H5P [imagen]. Interactive Video. 2013. [Consultado: 13 de octubre de 2017]. Disponible en Internet: https://h5p.org/interactive-video 4.4.5. Liferay Portal. Framework open source para crear portales corporativos, distribuido bajo la licencia GNU LGPL y escrito en Java.29 Es principalmente usado para el desarrollo de intranets, pues integra de manera nativa diversas aplicaciones usadas en este tipo de soluciones web, mas no está para nada limitado a ellas.30 La figura 7 presenta un vistazo general de la arquitectura de software de la plataforma. _______________________ 28 Joubel. Interactive Video [en línea]. H5p.com. (06 de octubre de 2013). [Consultado: 13 de octubre de 2017]. Disponible en Internet: https://h5p.org/interactive-video 29 Liferay. Introduction to liferay development [en línea]. Dev.liferay.com. [Consultado: 13 de octubre de 2017]. Disponible en Internet: https://dev.liferay.com/es/develop/tutorials 30 RIGSBY, Josette. Gartner's Magic Quadrant For Horizontal Portals: Oracle, IBM, Microsoft, SAP, Liferay Top Dogs [en línea]. Cmswire.com. (11 de octubre de 2012). [Consultado: 13 de octubre de 2017]. Disponible en Internet: https://goo.gl/EgKknz

31

Figura 7. Principales componentes de la arquitectura de Liferay Portal

Fuente: Liferay. Principales componentes de la arquitectura de Liferay Portal [imagen]. INTRODUCTION TO LIFERAY DEVELOPMENT. [Consultado: 13 de octubre de 2017]. Disponible en Internet: https://dev.liferay.com/es/develop/tutorials Como éste busca ser una solución multipropósito, el código base es extenso y complejo. Es por esto que el proceso de extensión de las capacidades nativas para la creación de portlets, aunque definido, es generalmente complicado pues la documentación está incompleta o desactualizada y la única opción integral sería tomar el curso oficial de pago.31 Aún así, una plataforma con un uso específico como lo sería Platea no amerita el uso de un framework amplio como Liferay en vista de la complejidad en su desarrollo.32

4.4.6. YouPHPTube. Framework open source para crear sitios web de compartición de videos similar a YouTube, y escrito en PHP. La plataforma realiza los procesos de descarga, carga, y codificación de videos tanto de plataformas de terceros como YouTube y Vimeo, como subidos de manera local.33

_______________________ 31 NOVIELLO, Riccardo. What is the best site to learn Liferay? [en línea]. Quora.com. (18 de marzo de 2015). [Consultado: 13 de octubre de 2017]. Disponible en Internet: https://www.quora.com/What-is-the-best-site-to-learn-Liferay 32 WAHNER, Kai. Pros and Cons – When to use a Portal and Portlets instead of just Java Web-Frameworks [en línea]. Dzone.com. (13 de octubre de 2011). [Consultado: 13 de octubre de 2017]. Disponible en Internet: https://dzone.com/articles/pros-and-cons-%E2%80%93-when-use 33 NETO, Daniel. Your own tube site [en línea]. YouPHPTube. [Consultado: 13 de octubre de 2017]. Disponible en Internet: https://www.youphptube.com/

32

En cuanto a integraciones sociales nativas, en comparación con Liferay, esta plataforma cuenta con más servicios pues el proceso de registro e inicio de sesión puede realizarse a través de Facebook y Google Plus, además de contar también con módulos para comentarios y calificaciones. La figura 8 muestra las interfaces default de la plataforma en sus versiones desktop y mobile. Figura 8. Interfaces desktop y mobile de la página de un video en YouPHPTube

Fuente: NETO, Daniel. Interfaces desktop y mobile de un video en YouPHPTube [imagen]. YOUR OWN TUBE WEBSITE. [Consultado: 13 de octubre de 2017]. Disponible en Internet: https://www.youphptube.com/ A partir de las características y objetivo de este framework se podría tomar como base para el desarrollo de la plataforma social del proyecto pues cuenta con todos los requerimientos necesarios y la simplicidad para modificar el código fuente, adaptar el look & feel de la interfaz, e integrar el player interactivo sin demasiadas complicaciones.

33

5. METODOLOGÍA

El sistema creado como resultado de este proyecto se desarrollará bajo la metodología de diseño centrado en el usuario (DCU), interpretándose como un subconjunto del diseño centrado en el humano (DCH), el cual está estandarizado internacionalmente mediante la norma ISO 9241-210:2010 como se describió en el marco referencial. Consiste en 4 etapas iterativas precedidas por una etapa preliminar de planeación, que puede ser entendida como el presente capítulo del documento, y seguidas por la terminación del sistema validado por usuarios representativos. La figura 9 muestra una representación visual del proceso y cada una de sus etapas: comprender y especificar el contexto de uso, especificar los requerimientos, producir soluciones de diseño, y evaluar contra los requerimientos.

Figura 9. Proceso de diseño centrado en el usuario

Fuente: ISO/TC 159/SC 4. Proceso de diseño centrado en el usuario [imagen].

ISO 9241-210:2010. 2010. 15, p. 11. [Consultado: 14 de octubre de 2017].

Disponible en Internet:

https://www.researchgate.net/figure/263429371_fig1_Figure-1-The-user-centered-

design-process-based-on-ISO-9241-2102010-15-p-11

5.1. CLASIFICACIÓN DE LA INVESTIGACIÓN Por la naturaleza del tratamiento de los datos a recopilar, este estudio se puede clasificar como una investigación de tipo mixto, pues a lo largo de las etapas planteadas se emplearán métodos de indagación de carácter estructurado que resultan en datos tanto cuantitativos como cualitativos.

34

Asimismo, teniendo en cuenta que el objetivo general de este proyecto es desarrollar un sistema alrededor de una temática relativamente nueva al asociar el concepto actual de video interactivo con multisensorialidad y plataformas web sociales; en cuanto a su alcance, se podrá considerar como un estudio exploratorio. Finalmente, en cuanto a fuentes de información, se trata de una investigación de campo, pues los datos a recopilar serán obtenidos directamente de la realidad social del grupo de usuarios objetivo. 5.2. RECOLECCIÓN DE LA INFORMACIÓN La obtención de datos necesarios para la investigación se realizará por medio de diversos métodos diseñados para aplicarse en la etapa correspondiente de la metodología seguida, y en función del diseño y desarrollo técnico del proyecto. Así, el cuadro 1 presenta un vistazo general de éstos, y se describirán en más detalle en los capítulos 6.3 y 6.4. Cuadro 1. Métodos de indagación a usar

Etapa Objeto de estudio

Herramienta empleada

Tipo de resultado

Iterativo

Análisis de usuarios,

especificación del contexto, y definición de

requerimientos

Usuarios del público objetivo

Encuesta digital

Cuantitativo No

Justificación

Con base en la disponibilidad de tiempo y acceso, y como primer contacto con la población objetivo, una encuesta permite obtener los datos cuantitativos necesarios para caracterizarlos y servir como fundamento para la posterior etapa de diseño.

35

Cuadro 1. (Continuación)

Etapa Objeto de estudio

Herramienta empleada

Tipo de resultado

Iterativo

Análisis de usuarios,

especificación del contexto, y definición de

requerimientos

Modelo de estudio del objeto físico

Concept testing

Cualitativo No

Justificación

En vista de los costos y logística asociados a la manufactura del objeto físico del módulo sensorial, es necesario hacer una validación previa con una representación física de la idea a desarrollar.

Interfaces del player y

plataforma web

Experimentos formales

Cuantitativo Sí

Justificación

Con este nivel de desarrollo avanzado, esta herramienta es ideal para identificar los problemas de usabilidad existentes, pues se analizan los verdaderos procesos de uso del sistema.

Validación de requerimientos con usuarios

Interfaces del player y

plataforma web

Escala de Usabilidad del Sistema

(SUS)

Cuantitativo Sí

Justificación

Previa aplicación de los experimentos formales, esta herramienta permite clasificar el sistema en un rango de usabilidad. Así, hasta este momento se va a obtener tanto un diagnóstico específico de los problemas existentes, como un puntaje de percepción general.

36

Cuadro 1. (Continuación)

Etapa Objeto de estudio

Herramienta empleada

Tipo de resultado

Iterativo

Validación de requerimientos con usuarios

Interfaces del player y

plataforma web

Entrevista estructurada

post-test Cualitativo Sí

Justificación

Esta herramienta permite hacer una revisión general de la experiencia específica de cada usuario. Esto permite obtener una retroalimentación importante para mejorar aspectos encontrados durante los experimentos formales.

5.2.1. Fuentes de datos y tamaño de la muestra. Todos los datos se obtendrán de una misma fuente primaria: los estudiantes de la asignatura de Video y Televisión Digital durante el período 2018-01, correspondientes a un total disponible de 19 personas, divididas entre 5 mujeres y 14 hombres. Las preguntas de la encuesta se pueden consultar en el Anexo E. 5.2.2. Análisis de la información. La información obtenida de las encuestas durante la primera aproximación a los usuarios será organizada mediante herramientas estadísticas simples como el cálculo de promedios y la identificación de modas, y será representada por medio de gráficas comparativas de barras y pastel para datos enteros y porcentuales respectivamente. Podrán ser consultadas en los anexos C y D. Igualmente, en vista de que el análisis de los datos asociados al proceso de validación de requerimientos corresponde a una de las etapas de la metodología planteada, se describirá en mayor detalle en el capítulo 6.4.

37

6. DESARROLLO, RESULTADOS Y DISCUSIÓN

A partir de la metodología planteada con sus 4 etapas iterativas, así como de la determinación de los datos a obtener, utilidad y posterior análisis, este capítulo presenta el procedimiento seguido para dar conclusión a los objetivos específicos propuestos y, por consiguiente, desarrollar la solución a la pregunta de investigación dentro del alcance descrito a lo largo de este trabajo. 6.1. DEFINICIÓN DE USUARIOS, CONTEXTO DE USO Y REQUERIMIENTOS Durante esta etapa se identificaron tanto el escenario geográfico donde se desplegará el sistema y sus características, como las particularidades sociales, económicas y educativas alrededor del entorno del usuario pertinentes al proyecto. El análisis de estos factores permitió comprender las necesidades que presentan alrededor de la temática de videos interactivos.

Así, a partir de este análisis se desarrollaron las primeras indagaciones a los estudiantes de Ingeniería Multimedia dentro del contexto de las clases de la asignatura de Video y Televisión Digital (V&TVD) que permitieron hacer una caracterización de su perfil de usuario. 6.1.1. Análisis de la competencia. Como parte del proceso para comprender el contexto del usuario es necesario analizar las alternativas con las que éste cuenta, pudiendo así no sólo comparar y denotar la propuesta de valor de este proyecto frente a éstas, sino también identificar puntos en común y puntos diferenciadores de cada una que puedan ser tenidos en cuenta para las etapas de diseño y desarrollo.

En este sentido, se realizó una indagación general alrededor de las dos temáticas principales del proyecto: reproductores/players para videos interactivos, y plataformas para la creación de sitios de compartición de videos con características sociales. Los resultados obtenidos para cada alternativa, y los criterios que se tuvieron en cuenta, se resumen en los cuadros 2 y 3 respectivamente.

38

Cuadro 2. Vistazo general de las alternativas para players interactivos

Alternativa

Características

Interacción básica

Interacción adicional

Versión gratuita

Open Source

Soporte sensorial

Facilita el desarrollo

Videopath X X

Wirewax X X X

RaptMedia X X X

H5P X X X X

Cuadro 3. Vistazo general de las alternativas para plataformas

Alternativa

Características

Módulo comentarios

Módulo calificación

Módulo social

Versión gratuita

Open Source

Facilita la modificación del

código base

Liferay Portal X X X X X

YouPHPTube X X X X X X

La investigación con una descripción y análisis más detallado de cada alternativa se puede encontrar en la sección del marco del estado actual en el capítulo 4.4. 6.1.2. Definición de la audiencia. Correspondió al trabajo de formalización de las características de diferentes índoles relevantes al enfoque del proyecto, encaminadas a la descripción de los usuarios del sistema y, por lo tanto, son el primer acercamiento a éstos. Asimismo, se hizo necesario realizar una descripción del entorno inmediato de la audiencia en los posibles espacios de interacción.

39

Consecuentemente, el análisis del ambiente, la definición del perfil de usuario y su posterior análisis, determinaron las bases sobre las cuales se debieron establecer los requerimientos para el desarrollo del proyecto a partir de las necesidades identificadas, tanto inherentes como contextuales. 6.1.2.1. Espacios a intervenir. Con el fin de analizar el contexto del usuario, se identificaron los posibles escenarios sobre los cuales se podría desplegar una experiencia interactiva con los fines propuestos en la definición del problema, encontrándose lo descrito en el cuadro 4. Cuadro 4. Descripción del contexto geográfico del usuario

Espacio Usuarios

potenciales

Actividades normalmente

realizadas

Elementos del entorno

Servicios disponibles

Laboratorio de

Computación Gráfica de la

UAO (Contenido

en el InfoLab)

Estudiantes de V&TVD

- Escuchar las clases teóricas. - Investigar acerca de los proyectos asignados como trabajo. - Desarrollar los proyectos. - Realizar preguntas al docente. - Presentar los resultados de los proyectos.

- Computadores de mesa. - Salón dividido en dos columnas. - Dos y tres computadores por fila. - Mesas con espacio limitado. - Pantalla. - Tablero.

- Préstamo de computadores portátiles de 13’’.

Estas características fueron tenidas en cuenta para el levantamiento de los requerimientos funcionales y no funcionales de todo el sistema. 6.1.2.2. Stakeholders. Son aquellas personas relacionadas con la problemática y cuya implicación en el proyecto incide en su desarrollo de una u otra forma y, por lo tanto, deben ser tenidas en cuenta durante todo el proceso.

40

Para el caso de este proyecto se determinó que los únicos stakeholders, y por lo tanto primarios, son los estudiantes de la clase de Video y Televisión Digital pues son aquellos a quienes la problemática involucra y afecta directamente, tal como se expuso en los capítulos de definición del problema y justificación. Por otro lado, el docente de la asignatura no se considera como un stakeholder debido a que su participación en la problemática se clasifica, más bien, como una de las consecuencias que inciden sobre el estudiante (calidad y calificaciones), mas no es parte del problema en sí mismo ni tiene control directo sobre él. 6.1.2.3. Definición del perfil de usuario y necesidades. Para la construcción del perfil de usuario se realizó una encuesta cuantitativa que buscó definir las características demográficas, de capacidades técnicas, y actitudinales y de comportamiento frente a las actividades de la asignatura relacionadas con el uso de videos interactivos. El guion de preguntas se puede encontrar en el Anexo E. Teniendo en cuenta que las preguntas relacionadas a las capacidades técnicas, actitudes y comportamientos serán las que determinarán en mayor medida los requerimientos de la solución, con base en las respuestas obtenidas se procedió a buscar patrones o respuestas comunes en estos resultados. La información numérica se transformó en las gráficas del Anexo C para facilitar su análisis y, finalmente, presentar las conclusiones que se pueden obtener de ellas, organizándose en tres categorías: aspectos demográficos, psicográficos, y conductuales, descritos a continuación.

Aspectos demográficos: se encontró que aproximadamente unos ¾ de la población corresponde al género masculino, con edades entre 19 y 26 años, estado civil de soltería, de estrato socioeconómico entre 3 y 4, y cursando semestres entre 7º y mayores a 10º. ● Aspectos psicográficos: los datos obtenidos indican que la mayoría tiende a ser emprendedora pues preferiría laborar creando una empresa propia/startup; realmente enfocándose en todos los ámbitos de la carrera, en especial el diseño y desarrollo de videojuegos, UX, UI, software y hardware, y producción audiovisual y 3D. El 100% prefiere la tecnología open source. A un 89.5% le interesa el video interactivo, prefiere desarrollar sus proyectos desde cero, pero estaría dispuesto a pagar por una herramienta que les facilite este proceso.

41

Un dato importante es que el 94.7% considera que la calidad de su trabajo mejoraría usando este tipo de herramientas, y que la multisensorialidad aumentaría la inmersión de los proyectos desarrollados. ● Aspectos conductuales: el 63.2% permanece en el salón de clases para índoles por fuera de actividades relacionadas a ésta, principalmente para realizar tareas especializadas de otras asignaturas, y como un lugar de reunión general. Un 57.9% afirma necesitar de herramientas de soporte, contrastando con un 47.4% que no las usa, mientras que un 42.1% lo hace siempre, y un 10.5% algunas veces. En cuanto a capacidades técnicas, el 78.9% ha usado Arduino, la mayoría considera que su nivel de programación es medio, y ya ha visto las asignaturas de interacción hombre-máquina y computación física. A partir de los resultados encontrados, se definieron tres necesidades que engloban la problemática identificada en el público objetivo, descritas a continuación:

Utilidad: debido a la carencia de una única plataforma que integre, al menos, todas las funcionalidades comunes (como se definió en el capítulo 2) de este tipo de sistemas, se ha generado un vacío por explotar en vista de que apenas poco más de la mitad de la población encuestada (57,9%) hace uso de herramientas de soporte. Sin embargo, y como contraste, también se ha expresado un interés enorme (94.7%) en el uso de éstos como medio facilitador para mejorar la calidad de los trabajos desarrollados. Esto también indica que la adición de interactividad no tradicional sería un plus considerable.

Acceso: igualmente, como complemento de la necesidad anterior, aunque se identificó que la mayoría de usuarios (89.5%) prefiere desarrollar desde cero, esta misma población también estaría dispuesta a pagar cierto valor monetario para acceder a servicios que les faciliten el desarrollo de sus proyectos. En este sentido, la gratuidad de una solución útil, en términos de completitud e innovación, es importante frente al hecho de que el 100% prefiere la tecnología open source.

Flexibilidad y uso: considerando que el 94.7% reafirma la utilidad de estas plataformas, es posible inferir que tanto las capacidades técnicas personales como el tiempo de desarrollo son los dos factores que influyen en este resultado. Así, en vista de que la población objetivo cursa semestres cuyas asignaturas corresponden a la mitad superior del pensum del Programa, y que se definen a si mismos con capacidades de programación medias, una solución que tenga en

42

cuenta ambos aspectos involucrados otorgaría una facilidad de uso, entendida como una reducción del tiempo invertido, y de amoldamiento e integración a otras soluciones o proyectos más grandes. En este sentido, se procedió a crear un perfil individual imaginario que correspondió a las características más representativas de la población encuestada. De esta forma se pudo tener datos específicos sobre los cuales desarrollar las siguientes etapas del proyecto. La figura 10 muestra la ficha creada. Figura 10. Ficha de la Persona creada

6.1.2.4. Definición del escenario de uso. Después de crear una persona a partir del perfil de usuario, se hizo necesario empatizar con ella de tal forma que se pudiera describir la situación o contexto general en la que probablemente se hará necesario usar el sistema. De este modo se pudo entender mejor sus objetivos y cómo el sistema propuesto lo ayudaría a conseguirlos. Asimismo, esta

43

herramienta permitió identificar la interacción entre los factores contextuales, limitaciones, dificultades, y expectativas. Para su desarrollo se hizo uso de un storyboard, presentado en la figura 11. Figura 11. Storyboard del escenario de uso

La lista de requerimientos funcionales y no funcionales se obtiene del análisis inicial realizado en esta etapa tanto a los usuarios como al contexto de uso. Para ambos casos se presentará un cuadro con la descripción del requerimiento y posibles notas de aclaración.

44

Debido a las características de las diferentes partes que conforman el sistema, éstos se clasificarán en 5 grupos distintivos con base en su función: reproducción del video, interactividad, plataforma social, módulo sensorial, y aspectos técnicos. 6.1.3. Eventos, interacciones y acciones. Antes de pasar a listar los requerimientos determinados, es pertinente destacar, en primera instancia, que como resultado del análisis a las necesidades de los usuarios, se identificaron las distintas interacciones virtuales y físicas que el sistema debe desplegar para dar cumplimiento a éstos. En este sentido, el cuadro 5 muestra una descripción de cada una de ellas. Cuadro 5. Lista de eventos e interacciones

Entorno

Evento

Nombre Descripción Tipo Descripción

Virtual

HOT_SPOT Representa un elemento o área clickeable.

IMAGE Inserta una imagen.

TEXT Inserta texto.

POLY Inserta un polígono.

ELLIPSE Inserta una elipse.

VIDEO Inserta un video.

WEB_CONTENT

Inserta contenido web externo en forma de un iframe.

45

Cuadro 5. (Continuación)

Entorno Evento

Nombre Descripción Tipo Descripción

Virtual INDEX

Crea un vínculo que permite cambiar el tiempo de reproducción del video, o el video en sí mismo. Es similar a un HOT_SPOT, pero se pensó para que sirviese como un índice dentro del video.

Físico SENSE

Representa una interacción que incide sobre factores ambientales.

WATER Genera un flujo de agua.

LIGHT Produce luz de colores.

SMOKE Produce humo.

WIND Genera un flujo de viento.

TEMP Genera un flujo de viento frío o caliente.

Igualmente, a cada interacción se le puede asignar una acción opcional, activada mediante clicks sobre el elemento, y descritas a continuación. Asimismo, el cuadro 6 muestra un resumen de las acciones disponibles para cada tipo de interacción. ● PLAY: reproduce el video en caso de que estuviera pausado. ● PAUSE: pausa el video. ● GOTO: cambia el tiempo del video o el video en sí mismo. ● NONE: no realiza ninguna acción al hacer click. ● EXTERNAL: ejecuta el tipo de evento físico correspondiente.

46

Cuadro 6. Lista de acciones

Entorno Tipo

Acciones

PLAY PAUSE GOTO NONE EXTERNAL

Virtual

IMAGE X X X X

TEXT X X X X

POLY X X X X

ELLIPSE X X X X

VIDEO X X X X

WEB_CONTENT X

INDEX X

Físico

WATER X

LIGHT X

SMOKE X

WIND X

TEMP X

6.1.4. Requerimientos funcionales. Corresponden a aquellos que hacen referencia a las funcionalidades del sistema, definiendo el qué mas no el cómo. Su consecución permitió el desarrollo del modelo funcional de los tres módulos. A continuación, se presentan en el cuadro 7.

47

Cuadro 7. Requerimientos funcionales del sistema

Categoría ID Descripción Notas

Reproducción del video

RF_01

El sistema debe permitir el control de la reproducción del video.

Nota 1 RF_01: Las opciones disponibles para controlar son:

● Reproducir ● Pausar ● Reiniciar ● Ciclo ● Silencio ● Volumen ● Velocidad de

reproducción ● Tiempo de

reproducción

RF_02

El sistema debe permitir la reproducción del video en modo fullscreen sin perder ninguna de sus funcionalidades.

RF_03

El sistema debe permitir modificar las características visuales del video para ajustarse a las preferencias del usuario.

Nota 1 RF_03: Los ajustes deben ser aplicados en tiempo real. Nota 2 RF_03: Los ajustes a modificar serán: desenfoque, filtro sepia, escala de grises, e invertir colores. Nota 3 RF_03: Se podrán aplicar todos los ajustes disponibles (4) de manera simultánea.

48

Cuadro 7. (Continuación)

Categoría ID Descripción Notas

Reproducción del video

RF_04

El sistema debe permitir la lectura, reconocimiento y despliegue de los 4 tipos de interactividad estipulados.

Nota 1 RF_04: Los tipos de interactividad disponibles son:

● HOT_SPOT ● WEB_CONTENT ● INDEX ● SENSE

Nota 2 RF_04: La posibilidad de interacción será determinada en función del tiempo de aparición y desaparición de cada una a partir de su configuración.

RF_05

El sistema debe permitir el control de la reproducción del video por medio del teclado.

Nota 1 RF_05: El mapeo de las funcionalidades será el siguiente:

● Play/Pause: barra espaciadora

● Flecha izquierda: disminuir velocidad de reproducción

● Flecha derecha: aumentar velocidad de reproducción

● Flecha arriba: aumentar volumen

● Flecha abajo: disminuir volumen

● Tecla “F”: activar/desactivar fullscreen

● Tecla “M”: mute/unmute

● Tecla “L”: loop/unloop

49

Cuadro 7. (Continuación)

Categoría ID Descripción Notas

Interactividad

RF_06

El sistema debe permitir al usuario hacer click dentro del área delimitada, para ejecutar las acciones descritas en el cuadro 6.

Nota 1 RF_06: Las áreas clickeables podrán ser:

● Polígonos ● Elipses ● Texto ● Videos ● Imágenes

Nota 2 RF_06: Este tipo de interacción podrá soportar todas las acciones virtuales.

RF_07

Para interacciones tipo WEB_CONTENT, el sistema debe permitir al usuario navegar por el contenido web presentado y hacer uso de sus funcionalidades propias.

Nota 1 RF_07: Este tipo de interacción no ejecutará ninguna acción, es decir, sólo serán de tipo NONE.

RF_08

Para interacciones tipo INDEX, el sistema debe permitir al usuario consultar la lista de ítems pertenecientes al índice del video, y ejecutar la acción correspondiente al hacer click sobre uno.

Nota 1 RF_08: La única acción posible será GOTO.

50

Cuadro 7. (Continuación)

Categoría ID Descripción Notas

Interactividad

RF_09

El sistema debe permitir al usuario la interacción por medio de clicks con los diferentes tipos de acciones estipuladas en la Nota 1 RF_10.

Nota 1 RF_09: Las acciones posibles son:

● PLAY ● PAUSE ● GOTO ● NONE ● SENSE

Nota 2 RF_09: Para todas las acciones en entorno virtual, la interacción se realiza por medio de clicks. Nota 3 RF_09: Para las acciones en entorno físico (SENSE), el usuario sólo percibe las respuestas físicas.

RF_10

La acción de GOTO deberá permitir cambiar el tiempo de reproducción del video, o cambiar el video.

Nota 1 RF_10: Si se cambia de video, las interacciones también deberán cambiar a las determinadas por su configuración.

RF_11

El sistema debe adaptar cada interacción con base en su configuración en el tiempo; de tal forma que el usuario, una vez haga click sobre el tipo de interacción virtual, ejecute la acción correcta en el tiempo.

Nota 1 RF_11: La configuración modificable corresponderá a opciones “de transformacion,” descritas en detalle en la sección 6.2.2.1.

51

Cuadro 7. (Continuación)

Categoría ID Descripción Notas

Plataforma Social

RF_12

La plataforma debe permitir a los usuarios crear cuentas.

Nota 1 RF_12: Los campos requeridos son:

● Nombre ● Usuario ● Email ● Contraseña

RF_13

La plataforma debe permitir a los usuarios iniciar sesión.

Nota 1 RF_13: Los campos requeridos son:

● Usuario ● Contraseña

RF_14

La plataforma debe permitir subir videos y asociarlos a las interacciones deseadas.

Nota 1 RF_14: Sólo si el usuario se encuentra autenticado. Nota 2 RF_14: Los formatos soportados serán MP4 y WEBM. Nota 3 RF_14: Los videos serán asociados a las interacciones (tanto virtuales como físicas) mediante un archivo JSON durante este proceso, inmediatamente después de cargar el video base. El sistema implementado para esto se describe en la sección 6.3.1.2.

RF_15 La plataforma debe permitir escribir comentarios.

RF_16 La plataforma debe permitir calificar un video.

Nota 1 RF_16: El video se podrá calificar mediante likes/dislikes.

52

Cuadro 7. (Continuación)

Categoría ID Descripción Notas

Plataforma Social

RF_17

La plataforma debe permitir compartir el video.

Nota 1 RF_17: Las opciones disponibles son:

● Facebook ● Twitter ● Google+ ● Email ● Embeber

RF_18

La plataforma debe permitir al usuario realizar búsquedas de videos.

Nota 1 RF_18: El único criterio de búsqueda será mediante coincidencias con el nombre del video.

6.1.5. Requerimientos no funcionales. Son aquellos que hacen referencia a los medios, restricciones, y objetivos; es decir, responden al cómo. Definieron lineamientos generales en cuanto a formas, capacidades, y estética. Su consecución permitió ajustar el modelo funcional previamente desarrollado a ciertas características que están encaminadas a mejorar la experiencia de uso a través de factores como la estabilidad, rapidez, estética y ergonomía, obteniendo como resultado el modelo prototipo del sistema. A continuación, se presentan en el cuadro 8.

Cuadro 8. Requerimientos no funcionales del sistema

Categoría ID Descripción Notas

Reproducción del video

RNF_01

El player interactivo debe ser multidispositivo y multiresolución.

RNF_02

Las imágenes e iconografía empleadas deben escalarse al espacio disponible.

53

Cuadro 8. (Continuación)

Categoría ID Descripción Notas

Reproducción del video

RNF_03

El sistema deberá proveer un feedback visual del estado actual para los elementos del tiempo de reproducción, volumen, y velocidad de reproducción.

RNF_04

El sistema debe ocultar la interfaz del player durante los momentos de desuso.

Nota 1 RNF_04: Se ocultará después de 4 segundos de inactividad o cuando el cursor no se encuentre sobre el área de reproducción del video.

Interactividad

RNF_05

El sistema debe escalar todos los elementos de interacción al tamaño de pantalla y espacio disponible, sin modificar la ejecución de sus acciones.

RNF_06

El sistema debe permitir la ejecución de todos los tipos de acciones en dispositivos móviles mediante taps.

Aspectos técnicos

RNF_07

El sistema debe interpretar las interacciones configuradas por medio de un archivo JSON que contendrá la información de las interacciones.

54

Cuadro 8. (Continuación)

Categoría ID Descripción Notas

Aspectos técnicos

RNF_08

El sistema deberá permitir su integración a cualquier plataforma que acepte la ejecución de código JavaScript.

Nota 1 RNF_08: Se deberá desarrollar dos versiones del player:

● Optimizada para la plataforma social

● Optimizada para usarse como plugin

RNF_09

El sistema debe permitir el acceso a funciones internas desde código externo.

RNF_10

La asignación asíncrona de eventos para la ejecución de las acciones de cada interacción debe destruirse una vez finalice su tiempo de aparición.

RNF_11

Las figuras de interacciones HOT_SPOT de tipo polígono deberán definirse mediante pares de coordenadas con base en el tamaño del rectángulo original.

Plataforma Social

RNF_12

La plataforma debe permitir la concurrencia de hasta 1000 usuarios sin afectar la latencia o estabilidad.

55

Cuadro 8. (Continuación)

Categoría ID Descripción Notas

Plataforma Social

RNF_13

La plataforma deberá estar en capacidad de almacenar los videos y sus interacciones.

RNF_14 El estilo y estética final de la plataforma deberá ser usable.

Módulo Sensorial

RNF_15

El módulo sensorial deberá “empaquetarse” como un sistema individual.

RNF_16

La estructura del objeto no deberá pesar más de 1kg para facilitar su manipulación.

RNF_17

Las medidas del objeto deberán permitir a una laptop de 13’’ acoplarse.

RNF_18

Los materiales de construcción deberán soportar líquidos sin afectar su integridad estructural.

RNF_19

La ejecución de las interacciones sensoriales no deberá afectar la integridad física del computador ni del objeto construido.

56

Cuadro 8. (Continuación)

Categoría ID Descripción Notas

Módulo Sensorial

RNF_20

El humo de las interacciones SMOKE no deberá dificultar la visualización del video.

RNF_21

El agua para las interacciones WATER no deberá “lanzarse” como un chorro sino en bruma.

RNF_22

La luz las interacciones LIGHT no deberá visualizarse como un solo foco, sino de manera distribuida.

RNF_23

El viento de las interacciones WIND y TEMP deberá estar dirigido hacia el usuario.

RNF_24

La activación de las placas Peltier para las interacciones TEMP deberá realizarse 10 segundos antes de su tiempo de ejecución, de tal forma que el efecto correspondiente tenga tiempo para generarse.

Nota 1 RNF_24: Esto sólo podrá ser aplicado para interacciones TEMP cuyo tiempo de ejecución sea después de los 10 segundos del video. Nota 2 RNF_24: Para interacciones que empiecen antes, el tiempo de activación de las placas Peltier será el inicio del video.

57

Cuadro 8. (Continuación)

Categoría ID Descripción Notas

Módulo Sensorial

RNF_25

El sistema debe permitir al usuario percibir las interacciones sensoriales.

Nota 1 RF_25: Las interacciones son:

● WATER ● SMOKE ● LIGHT ● TEMP ● WIND

Interacciones virtuales

RNF_26

Para todos los tipos de interacciones virtuales, el sistema deberá desplegar cada una con base en su configuración de apariencia.

Nota 1 RNF_26: Los detalles de la configuración estética para cada tipo de interacción se pueden encontrar en la sección 6.2.2.1.

RNF_27

Las rutas de las imágenes y videos para interacciones tipo IMAGE y VIDEO respectivamente, deberán ser absolutas.

RNF_28

Para interacciones POLY, los lados del polígono se definirán a partir de un ancho y alto configurables, y de pares de coordenadas correspondientes a vértices.

RNF_29

Para interacciones ELLIPSE, las elipses se definirán a partir de un ancho y alto configurables.

Nota 1 RNF_29: Si tanto el ancho como el alto son el mismo valor, se formará un círculo perfecto.

58

Cuadro 8. (Continuación)

Categoría ID Descripción Notas

Interacciones virtuales

RNF_30

Para interacciones WEB_CONTENT, el sistema sólo deberá requerir de la URL absoluta para mostrar el contenido correspondiente.

6.1.6. Historias de usuario. Con el fin de determinar si todos los requerimientos eran realmente necesarios y estaban completos, se crearon diferentes historias de usuario como método para agrupar las funcionalidades requeridas para que éste pueda completar diferentes objetivos a través del uso del sistema. De esta forma se determinó cuáles debían ser priorizados y cómo determinar su consecución durante la etapa de desarrollo. En este sentido, cada historia de usuario se representó por medio de un cuadro donde se muestra su descripción, criterios de validación, prioridad, y requerimientos de los que depende. Todas pueden ser encontradas en el anexo A. Asimismo, a continuación, en el cuadro 9 se muestra un ejemplo con el formato seguido. Cuadro 9. Ejemplo del esquema para historias de usuario

ID #: 1 Título: Modificar las opciones visuales del video

Descripción: COMO estudiante de V&TVD

QUIERO ajustar las características visuales del video

PARA facilitar el consumo de su contenido

59

Cuadro 9. (Continuación)

Criterios de validación:

El video ahora se visualiza con los filtros correspondientes aplicados en tiempo real.

RF’s asociados

RNF’s asociados

Prioridad: Baja RF_03 RNF_02

RNF_03

RNF_04

6.2. DISEÑO Y PROPUESTA DE SOLUCIÓN Habiendo determinado los requerimientos asociados al proyecto que definieron a los usuarios y su contexto, es entonces posible pasar a generar soluciones de diseño que cumplan con éstos. En este sentido, durante esta etapa se produjeron los primeros prototipos con base en los parámetros establecidos para cada módulo del sistema propuesto, así como las interfaces de comunicación. 6.2.1. Diseño de interfaces gráficas. Durante el diseño de las interfaces para el player y la plataforma social no se realizó un proceso de prototipado de baja fidelidad, sino que se pasó directamente al prototipado interactivo y funcional partiendo del hecho de que el diseño para todos los reproductores de video es básicamente el mismo: una barra de controles para el playback, el volumen, y configuraciones del video, también identificados en la encuesta inicial. A pesar de que su posicionamiento puede cambiar, las variaciones entre los modelos mental y conceptual del usuario pueden ser rápidamente captadas. Igualmente, la aplicación de affordances en los controles disminuye la dificultad de asimilación en caso de existir grandes diferencias. Respecto a la plataforma, los argumentos para esta decision se expondran en mayor detalle en la seccion “Diseno preliminar de la plataforma social” en la continuacion de este capitulo. 6.2.1.1. Prototipo preliminar del player. En este sentido, se creó un primer modelo que implementaba todos los requerimientos funcionales del player, sobre el cual se pudieran seguir realizando mejoras durante las posteriores iteraciones en la etapa de validación.

60

En cuanto a la interfaz, se decidió ubicar la barra de controles en la parte inferior para no diferir de la mayoría de interfaces de reproductores de video. Para los elementos contenidos en ella se decidió dividirlos en dos grupos: controles de playback y control del volumen, ubicándose al costado derecho e izquierdo respectivamente. Los elementos adicionales que componen la interfaz, pero no hacen parte de los controles típicos, se ubicaron en la esquina superior derecha en forma de lista vertical accionable por medio de botones con contenido desplegable de manera horizontal. Las figuras 12 y 13 muestran su interfaz. Figura 12. Diseño preliminar del player

Figura 13. Menú desplegable para elementos adicionales de la interfaz del player

6.2.1.2. Diseño preliminar de la plataforma social. Para el desarrollo de la plataforma se decidió implementar el framework YouPHPTube como se describirá en mayor detalle en la seccion “Plataforma web social”. Éste cuenta con una

61

estética basada en el diseño actual de YouTube y, por lo tanto, al tener una interfaz relativamente parecida la experiencia de usuario también es similar al menos en términos de usabilidad, por lo cual tampoco se realizó un proceso de prototipado de baja fidelidad de la GUI desde cero sino que se partió de la base que la plataforma proveía. Sin embargo, durante la cuarta etapa de la metodología sí se realizarán pruebas de usabilidad para identificar y tratar posibles inconvenientes restantes. Las figuras 14 y 15 muestran la interfaz preliminar. Figura 14. Interfaz de la página principal de la plataforma

Figura 15. Interfaz de la página de un video de la plataforma

62

6.2.2. Arquitectura del sistema. La arquitectura del sistema es un pilar fundamental para el desarrollo del proyecto pues determina parte de la viabilidad y del grado de dificultad para implementar en gran medida los requerimientos funcionales y no funcionales. Así, el diagrama de despliegue correspondiente se muestra a continuación en la figura 16. Figura 16. Diagrama de despliegue del sistema

El backend, correspondiente a una base de datos MySQL y un servidor web Apache con la plataforma social, se montará en una instancia de Elastic Computing (EC2) de Amazon Web Services en el que se instalarán las dependencias requeridas para su funcionamiento. La conexión con el frontend corresponderá a una arquitectura tradicional cliente-servidor basada en peticiones síncronas. El cliente hace referencia al navegador web del usuario, en el cual estarán contenidos el player interactivo a desarrollar, así como el código correspondiente a la comunicación con el objeto físico sensorial. Este último componente se encargará de realizar una conversión de la información recibida para cada interacción a un formato de datos que el sistema físico pueda comprender.

63

Finalmente, la comunicación entre el objeto físico y el cliente se hará mediante el protocolo Firmata, y el elemento de procesamiento será un sistema embebido. Los detalles del proceso de definición e implementación de cada nodo se podrán encontrar en detenimiento en el capítulo 6.3. 6.2.2.1. Archivo JSON de interacciones. El sistema recibe como input del usuario creador del video un archivo en formato JSON que describe las características de cada interacción virtual y física. Cabe resaltar que el alcance de este proyecto no contempla el desarrollo de un sistema visual que facilite la creación de este archivo de configuración; es decir, éste debe ser creado manualmente por los usuarios, y asociado al video base como se describirá en la sección 6.3.1.2. En este sentido, la figura 17 muestra su esquema general. El archivo se compone en su nivel root de un arreglo de interacciones interactions (array de objects) cuyas propiedades en común se describen a continuación. ● id (string): es el identificador único para cada interacción. ● show_time (number): determina el tiempo, en segundos, en el que la interacción debe empezar. ● duration (number): determina, en segundos, la duración total de la interacción. ● isPaused (boolean): determina si el video debe ser pausado mientras la interacción esté ocurriendo. ● type (object): determina las características generales de la interacción. ○ event (string): determina el tipo de interacción. Puede ser: “HOT_SPOT”, “WEB_CONTENT”, “INDEX”, o “SENSE”. ○ data (object): determina las características específicas de la interacción con base en el tipo de evento. ■ action (string): determina la acción a ejecutarse si se hace click sobre el elemento. Puede ser: “PAUSE”, “GOTO”, “NONE”, “PLAY”, o “EXTERNAL”.

64

Figura 17. Esquema del archivo JSON

{

"interactions": [

{

"id": "00001",

"type": {

"event": "HOT_SPOT",

"data": {

"action": "PAUSE",

"shift": [

{

"type": "POLY",

"geometry": {

"width": 40,

"height": 60,

"vertices": [

{

"x": 50,

"y": 0

}, {...}, {...}, {...}

]

},

"transform": [

{

"type": "TRANSLATE",

"start_time": 1,

"duration": 5,

"translate": {

"x": 5,

"y": 30

}

}, {...}, {...}, {...}

]

}

]

}

},

"show_time": 1,

"duration": 10,

"isPaused": false

}

]

}

65

La siguiente propiedad shift (array de objects) determina las características morfológicas de la interacción. Su contenido depende del tipo de evento definido anteriormente. Sin embargo, todas tienen una propiedad común transform (array de objects) que especifica los parámetros del estado temporal y espacial de la interacción para un plazo de tiempo dado; por lo cual se requiere especificarle las propiedades start_time y duration que determinan el tiempo de inicio y la duración, en segundos, de ese estado de la interacción, así como su posición por medio de la propiedad translate (object) que requiere x (number) e y (number), cuyas unidades en CSS serán porcentajes para posicionar el elemento de manera relativa al contenedor padre del video. En este sentido, el esquema de la propiedad shift de cada tipo de event se describe a continuación. 6.2.2.2. JSON: Esquema de shift para interacciones HOT_SPOT. Las propiedades internas se describen a continuación. Asimismo, las figuras 18, 19 y 20 muestran el esquema para sus variaciones. ● type (string): determina el tipo de la geometria. Puede ser “POLY” o “ELLIPSE” para crear un area clickeable en forma de polígono o elipse respectivamente, o “VIDEO” y “TEXT”. ● transform (array de objects): además de contener las propiedades descritas anteriormente, debe definir al menos 1 objeto pues este atributo funciona a modo de un frame para la interacción. En caso de querer aplicar una rotación al elemento se deberá definir un rotate (object) que contendrá deg (number) para especificar cuántos grados se rotará alrededor del eje z con respecto al centro vertical y horizontal del elemento, es decir al valor inicial de la propiedad CSS transform-origin: 50% 50%. Si el tipo de shift es un “POLY” o “ELLIPSE”, el contenido unico es el siguiente. ● geometry (object): determina los parámetros de la geometría: width (number) y height (number) para definir su ancho y alto respectivamente. En caso de que el tipo sea “POLY”, se debe especificar vertices (array de objects) con propiedades x (number) y y (number) que determinan las coordenadas de un punto hasta definir todos los vértices del polígono descrito. Cabe destacar que la escala de la geometría se controla directamente con width (number) y height (number), y por eso no se define una propiedad scale para transform.

66

Figura 18. Shift de interacciones HOT_SPOT para tipos POLY y ELLIPSE

"shift": [

{

"type": "POLY",

"geometry": {

"width": 40,

"height": 60,

"vertices": [

{

"x": 50,

"y": 0

}, {...}, {...}, {...}

]

},

"transform": [...]

}

]

Si el tipo de shift es un “TEXT”, el contenido unico es el siguiente. Notese que en caso de necesitar modificar propiedades distintas a posición o temporalidad de la interacción, se deberá definir un nuevo objeto dentro de shift. ● font (object): determina las características de la tipografía, así como su contenido, el cual puede ser cualquier elemento HTML5 válido dentro de un tag <div>. La estructura actual permite modificar las propiedades CSS: font-family, font-size, color, text-decoration, font-weight, background-color, line-height, y padding. Los tipos de valores específicos para cada una se pueden determinar de la figura 19. Si el tipo de shift es un “VIDEO” o “IMAGE”, el contenido unico es el mostrado en la figura 20, reemplazando el valor de type al correspondiente. Las propiedades width y height actúan de la misma forma que las definidas dentro de geometry. ● src (string): determina la ruta relativa al video a reproducirse o a la ruta absoluta a la imagen.

67

Figura 19. Shift de interacciones HOT_SPOT para tipo TEXT

"shift": [

{

"type": "TEXT",

"html":

"<a href='https://www.youtube.com/watch?v=O1KW3ZkLtuo' target='_blank'>Cats meow

meow!</a>",

"font": {

"family": "Arial",

"size": 3,

"color": "#ffffff",

"decoration": "underline",

"weight": "300",

"backgroundColor": "#4cddb0",

"lineHeight": 3,

"padding": [0.6, 1]

},

"transform": [

{

"type": "TRANSLATE",

"start_time": 0,

"duration": 3,

"translate": {

"x": 35,

"y": 10

}

}, {...}, {...}

]

}

]

Figura 20. Shift de interacciones HOT_SPOT para tipo VIDEO

"shift": [

{

"type": "VIDEO",

"src": "../videos/videoPrueba.mp4",

"width": 50,

"height": 50,

"transform": [

{

"type": "TRANSLATE",

"start_time": 8,

"duration": 10,

"translate": {

"x": 30,

"y": 25

}

}

]

}

]

68

Cabe resaltar que este tipo de interacción sólo funciona, hasta el modelo prototipo final desarrollado, en la versión del player integrado como plugin por fuera de la plataforma social; ya que para integrarse a ésta, la ruta al video a reproducirse debe ser dinámica, pudiéndose configurar desde algún tipo de aplicación que permita crear el archivo JSON en sí mismo dependiendo de qué videos no interactivos se hayan cargado a la base de datos, o incluso se podría considerar importarlos desde otras plataformas. Sin embargo, el desarrollo de este tipo de funcionalidad está por fuera del alcance del presente proyecto. Una alternativa para integrar picture-in-picture en la plataforma sería hacer uso de las capacidades para embeber los reproductores de otras plataformas como YouTube o Vimeo a través del link generado para tal uso, y ser desplegados por medio del iframe de una interaccion “WEB_CONTENT” que si puede funcionar en ambas versiones del player interactivo. 6.2.2.3. JSON: Esquema de shift para interacciones WEB_CONTENT. Las propiedades internas se describen a continuación. Asimismo, la figura 21 muestra su esquema. Las propiedades width y height actúan de la misma forma que las definidas dentro de geometry. ● src (string): determina la ruta absoluta a la página a cargarse mediante un iframe. Figura 21. Shift de interacciones WEB_CONTENT

"shift": [

{

"src": "http://www.uao.edu.co/",

"width": 80,

"height": 80,

"transform": [

{

"type": "TRANSLATE",

"start_time": 12,

"duration": 15,

"translate": {

"x": 10,

"y": 5

}

}

]

}

]

69

6.2.2.4. JSON: Esquema de shift para interacciones INDEX. Las propiedades internas se describen a continuación. Asimismo, la figura 22 muestra su esquema. ● label (string): determina el texto mostrado como ítem de la lista índice de secciones del video. Si se especifica la propiedad font (object), los estilos definidos anteriormente serán aplicados. Figura 22. Shift de interacciones INDEX

"shift": [

{

"label": "Ir a 0:0:15",

"font": {...},

"transform": [

{...}

]

}, {...}, {...}

]

6.2.2.5. JSON: Esquema de shift para interacciones SENSE. Las propiedades internas se describen a continuación. Asimismo, la figura 23 muestra su esquema. ● type (string): determina el tipo de interacción sensorial. Puede ser “WIND”, “WATER”, “SMOKE”, “TEMP” o “LIGHT”. Todos los tipos de interacciones sensoriales tienen el mismo contenido para la propiedad transform, a excepcion de “LIGHT” y “TEMP” que se describiran a continuación. Si es de tipo “LIGHT”, su contenido unico es el mostrado por el esquema de la figura 24. ● color (array de numbers): determina el valor de intensidad para cada canal del modelo RGB en ese orden.

70

Figura 23. Shift de interacciones SENSE

"shift": [

{

"type": "WIND",

"transform": [

{

"start_time": 0,

"duration": 4

},

{

"start_time": 7,

"duration": 3

},

{

"start_time": 19,

"duration": 5

}

]

}

]

Figura 24. Transform de interacciones SENSE para tipo LIGHT

"shift": [

{

"type": "LIGHT",

"transform": [

{

"color": [255, 0, 0],

"start_time": 0,

"duration": 3

}, {...}, {...}

]

}

]

Si es de tipo “TEMP”, su contenido unico es el siguiente. Asimismo, la figura 25 muestra su esquema. ● state (number): determina cuál de los dos módulos de placa peltier + disipadores + ventilador debe usarse para generar la sensación deseada, siendo 0 equivalente a calor y 1 a frío.

71

Figura 25. Transform de interacciones SENSE para tipo TEMP

"shift": [

{

"type": "TEMP",

"transform": [

{

"state": 0,

"start_time": 18,

"duration": 2

},

{

"state": 1,

"start_time": 31,

"duration": 3

}

]

}

]

6.3. DESARROLLO INTEGRAL DEL SISTEMA Posterior a la etapa de diseño y planeación del sistema, y continuando con el flujo de la metodología seguida, el proceso de desarrollo técnico del sistema se llevará a cabo en esta etapa, lo cual implica que será la que requiera una mayor inversión de recursos monetarios, tecnológicos y temporales durante todo el proyecto. Hasta este punto no se requerirá la recolección de ningún tipo de métrica por parte de usuarios pues aún hace parte del proceso evaluativo preliminar encaminado a la corrección de errores que se encuentren durante el desarrollo. Esto con el objetivo de presentar al menos un modelo funcional del sistema entero antes de llegar a las pruebas con usuarios. Como resultado final de todas las iteraciones de este proceso se obtendrá un producto mínimo viable (PMV) semi-validado en términos del cumplimiento de requerimientos fundamentales tanto del player interactivo como del objeto físico para las interacciones sensoriales, de la plataforma social, y de toda la arquitectura de soporte existente. Sin embargo, las pruebas de aceptación finales de cada iteración se darán con usuarios reales en la siguiente etapa de la metodología.

72

6.3.1. Software. Considerando que este proyecto buscaba la creación de una plataforma similar a YouTube enfocada a videos interactivos, el entorno sobre el cual se debía implementar era Internet. Se hizo entonces evidente que el desarrollo de todo el código frontend debía hacerse bajo las tecnologías web estándar: HTML5, CSS3, y JavaScript. Para el caso de los estilos, se decidió emplear SASS en su sintaxis de SCSS como preprocesador, junto a la metodología Block Element Modifier (BEM) para facilitar su desarrollo. Así, el software del sistema se divide en tres partes: el reproductor interactivo, la plataforma social, y el servidor que implementa la comunicación entre los módulos virtual y físico. A continuación, se detalla el proceso de desarrollo de cada uno. 6.3.1.1. Player interactivo. La fase de desarrollo técnico inició con la implementación del prototipo preliminar del player como se mostró en los capítulos anteriores. Para esto se consideró que para cumplir con los requerimientos de soportar el despliegue de todas las interacciones básicas, era necesario crear y eliminar dinámicamente múltiples elementos gráficos en el Document Object Model (DOM). Consecuentemente, con base en las características visuales necesarias, se consideró la integración de una librería externa para facilitar esta tarea. A continuación, se describen las dos opciones principales encontradas. ● p5.js: Es una librería que comparte el objetivo original de Processing, hacer a la programación accesible para artistas, diseñadores, educadores, y principiantes, reinterpretando esto para la web actual. Posee un amplio rango de funcionalidades relacionadas con el dibujo. Sin embargo, no se está limitado al dibujo pues integra diversas librerías que facilitan la interacción con otros objetos HTML5, incluyendo texto, inputs, video, webcam, y sonido. p5.js es una nueva interpretación en vez de un emulador o un port. ● Processing.js: Es el proyecto hermano del lenguaje de programación visual Processing, pero diseñado para la web. Actúa como un compilador capaz de leer y parsear archivos .pde estándar, permitiendo la ejecución de cualquier sketch escrito en processing desde un navegador web. Ambas opciones permitían cumplir con los requerimientos funcionales asociados al player, por lo que se pasó a analizar la facilidad de uso e integración con el resto de la arquitectura y el entorno en el que se desplegaría. Processing.js requeriría escribir un archivo de código adicional en Processing e importarlo a otro archivo JavaScript que ya era necesario para ambas opciones, lo cual incrementaría la complejidad para el desarrollo iterativo, además de romper con la

73

uniformidad de mantener todo el código base en JavaScript por su facilidad para poder ser interpretado directamente por los navegadores sin compiladores intermedios. Por otro lado, p5.js sí puede ser integrado y ejecutado directamente; además, en vista de que se desarrollaría sólo en JavaScript, se tiene acceso a todas las características del lenguaje, lo cual también facilitaría la estructuración del player a modo de plugin que pueda ser implementado en otros entornos diferentes a la plataforma social aquí propuesta. Por tal motivo se determinó el uso de p5.js como librería de desarrollo y soporte para crear el player interactivo. Para esto también se incluyó la librería que le permite acceder a funcionalidades relacionadas con la navegación y modificación del DOM: p5.dom. Finalmente, luego de terminar con el desarrollo, se realizaron cambios al diseño del prototipo preliminar, los cuales pueden verse reflejados en la figura 26. Las modificaciones más notables son el intercambio en la posición de los elementos de la barra de controles para que la distribución se asimilara a la de otras plataformas, el estado inicial de toda la interfaz tiene una opacidad de sólo el 50% para no interferir con el contenido hasta hacer hover con el cursor, además de incrementar el tamaño del ícono seleccionado; este estado puede verse en la figura 27; y finalmente, teniendo en cuenta el contexto de uso del sistema, el color principal de la interfaz se cambió a un rojo puro (#FF0000) por ser el usado como el color institucional de la Universidad. Figura 26. Diseño final del player usado como primer prototipo para pruebas.

74

Figura 27. Estado on hover de los controles

La interfaz de los controles se dividió en dos categorías: visualización y media, ubicadas en la parte izquierda y derecha respectivamente. A su vez, visualización se organizó en dos subcategorías: despliegue y playback, distribuidas de la misma manera. La iconografía empleada fue escogida por emplear las convenciones estándar para las acciones que representan, siendo tomada del servicio FontAwesome en su versión gratuita. Visualización se ubicó en la parte izquierda de tal forma que se asimilara más (versus la versión preliminar del player en la figura 12) a la distribución de YouTube por ser la plataforma similar con mayor experiencia de uso del público objetivo, ajustándose en mayor medida a su modelo mental. Despliegue, en vista de que se conforma sólo por el botón de fullscreen frente a los 5 de playback, se ubicó en el costado izquierdo de éstos en vez del derecho, ya que de lo contrario el “flujo natural de izquierda a derecha” en el que se lee el contenido cortaría con su subcategoría y terminaría la categoría padre abruptamente. Asimismo, los íconos de atrasar y adelantar se posicionaron a los extremos del de reproducir/pausar, de nuevo para seguir con la convención existente respecto a estas acciones y ajustarse al modelo mental de los usuarios. El ícono de stop se ubicó próximo al de atrasar pues es probable que estas dos opciones, al igual que los íconos de loop y adelantar, se utilicen en conjunto. Por otro lado, en vista de que se decidió desplegar la barra para modificar el volumen del video de tal forma que fuera más fácilmente accesible, la categoría media se separó y se ubicó al otro lado de la interfaz para reforzar esta separación conceptual de los controles. En este sentido, esta versión fue usada como el primer modelo prototipo durante las pruebas realizadas en la cuarta etapa de la metodología. 6.3.1.2. Plataforma web social. Para su desarrollo se tuvieron en cuenta las dos opciones descritas en el marco del estado actual y resumidas en la sección 6.1.1. A partir del análisis presentado en el cuadro 3, se puede evidenciar que ambas plataformas cumplen con los requerimientos funcionales básicos. Al igual que con el player interactivo, se pasó a considerar el criterio de la facilidad para extender y

75

modificar el código base, lo cual concluyó en YouPHPTube como la alternativa elegida. Esta plataforma está desarrollada en PHP e implementa una base de datos MySQL. Al ser un sistema orientado a la función específica de desarrollar sitios web de compartición de videos, y por ser un proyecto relativamente nuevo y desarrollado por particulares, los archivos base son fáciles de navegar y modificar. Como entorno para montar la plataforma, se determinó usar una instancia t2.micro bajo el modelo de la capa gratuita de Amazon Web Services (AWS), a recomendación de sus creadores en la guía de implementación. Ésta ofrece una disponibilidad de 750 horas mensuales por 1 año sin generar cobros. Luego, se procedió a instalar todas las dependencias de YouPHPTube: Apache, nginx, PHP, MySQL, ffmpeg, y youtube-dl, para finalmente instalar y configurar la plataforma como tal. Posteriormente, se procedió a integrar el player desarrollado anteriormente, reemplazando el que se incluye por defecto. Para esto fue necesario incluir los archivos JavaScript y CSS en los archivos originales de la plataforma y referenciarlos en el archivo plantilla “video.php” que se encarga de renderizar la página de visualización de un video. Finalmente, para asociar el video a reproducirse con el nuevo player, simplemente se reemplazó la consulta original a la base de datos con la opción del player para el atributo “src” del elemento HTML5 <video> que se crea automáticamente con la integración del plugin desarrollado. Por otro lado, teniendo en cuenta que el player necesita un archivo JSON como descripción de las interacciones que debe ejecutar (tanto virtuales como físicas), proceso que sera detallado en la seccion posterior “Archivo JSON de interacciones”; tambien fue necesario modificar el proceso de carga de un nuevo video. La interfaz del proceso original se puede ver en la figura 28. Para añadir esta funcionalidad, inicialmente fue necesario modificar el archivo “upload.php” para integrar un input HTML5 de tipo file con el cual el usuario pudiera cargar el archivo .json. Se hizo uso de un evento nativo de la plataforma que se dispara una vez el archivo del video termina de cargarse para hacer aparecer este nuevo elemento que se encuentra inicialmente oculto, y así evitar que el JSON se cargue antes que el video y ocurran errores debido a la estructura de la base de datos. Los cambios visuales en la interfaz se pueden ver a continuación en la figura 29.

76

Figura 28. Interfaz original de carga de un video

Figura 29. Interfaz modificada para permitir asociar un archivo JSON con el video cargado

Consecuentemente, fue necesario modificar el diseño original de la base de datos para almacenar este nuevo archivo. Para facilitar este proceso se instaló phpMyAdmin en la instancia de AWS, y se procedió a crear una nueva columna en la tabla de videos. Asimismo, también se creó un nuevo archivo llamado json-upload.php para manejar el nuevo proceso de conexión y comunicación con la base de datos para almacenar el archivo. Esta modificación a la tabla de “videos” se muestra en la figura 30 al final del listado de las columnas. El MER completo se puede encontrar en el anexo F.

77

Figura 30. Nuevo campo json en la tabla “videos” del MER de la base de datos

Finalmente, una vez vinculados el video y su archivo JSON, se procedió a realizar una consulta a la base de datos para obtener la información de las interacciones y cargarlas en el player interactivo, de la misma forma que se hizo para obtener la información del video a reproducirse. 6.3.1.3. Servidor. Para la comunicación entre el frontend de la plataforma y player interactivo con el módulo físico de interacciones sensoriales, se necesitó crear un programa de recepción de datos, procesamiento de la información, y transmisión de órdenes que los conectara en tiempo real para la sincronización de interacciones virtuales y físicas en función del tiempo de reproducción actual del video siendo visualizado. En este sentido, con el fin de intentar mantener todo el código desarrollado usando JavaScript, se optó por emplear Node.js a través de la creación de un servidor con un middleware manejado por Express.js.

78

Luego, partiendo del requerimiento de tiempo real, se indagaron los medios existentes para implementar este tipo de comunicación, encontrándose que la tecnología más adecuada y sencilla de implementar para este proceso es la de websockets. Ahora bien, existen diversas librerías para facilitar este proceso, siendo las más prominentes Socket.io, uWebSockets, y ws. En vista de que las tres alternativas cumplen a cabalidad la funcionalidad básica requerida, se escogió emplear Socket.io por tener la mejor documentación, comunidad, y soporte para facilitar el proceso de desarrollo. Posteriormente, haciendo uso de las funcionalidades disponibles de Socket.io, se definieron dos eventos enviados desde el código del player interactivo para ser detectados por el servidor: video y sense. El primero se encarga de enviar el tiempo de reproducción actual del video siendo visualizado, de tal manera que éste se ejecuta constantemente, permitiendo sincronizar ambos sistemas. El segundo se encarga de recibir la información correspondiente a interacciones definidas como sensoriales en el JSON leído por el código del player, las cuales serán manejadas por funciones definidas en el mismo código del servidor. 6.3.2. Hardware. El componente de hardware del proyecto se constituye por el módulo de interacciones sensoriales cuyo proceso de desarrollo físico se dividió en dos categorías con base en la lista de requerimientos: los componentes funcionales para ejecutar las interacciones, y los componentes no funcionales relacionados al proceso de manufactura, tales como materiales y medidas. En este sentido, como primer paso se realizó un análisis funcional a través de la herramienta de caja negra para identificar las funciones principales que el sistema debía realizar, por medio de la definición de los inputs y outputs que el sistema debería recibir y generar respectivamente. La figura 31 muestra el resultado. Figura 31. Diagrama de caja negra del módulo sensorial

79

Por medio de este diagrama se pudo representar visualmente los diferentes tipos de interacciones desplegadas, y cuyas formas de producción serán descritas en detalle en el siguiente apartado. 6.3.2.1. Componentes electrónicos para interacciones sensoriales. Con base en las interacciones físicas determinadas por los requerimientos funcionales del módulo sensorial, y el diagrama de la caja negra, a continuación se describe el método seguido para la creación de cada uno de los efectos. Se usó una protoboard, cables DuPont, y resistencias variadas para interconectar los componentes. ● Viento: se emplearon x3 disipadores pequeños de 12V de 40x40x10mm para producir el viento. El control de encendido/apagado se realizó de manera individual. La figura 32 muestra el modelo usado.

Figura 32. Modelo de ventilador usado

● Agua: se empleó x1 microbomba sumergible de 3-5V con caudal de 70-120L/h para bombear el agua desde un recipiente hacia una manguera cerrada del otro extremo en la cual se insertaron x7 boquillas de nebulización. La figura 33 muestra el esquema de funcionamiento del sistema.

80

Figura 33. Esquema de funcionamiento para la interacción de agua

● Humo: se empleó un humidificador ultrasónico en un montaje idéntico al de la microbomba para producir un leve vapor de agua al estar sumergido en su recipiente, pero sin la necesidad de integrar una manguera. La figura 34 muestra el modelo usado. Figura 34. Humidificador ultrasónico para el módulo de humo

● Luz: se empleó una cinta de 1m x60 LEDs RGB no direccionable modelo SMD5050 de 12V. Adicionalmente, para controlar los colores producidos se emplearon x3 transistores TIP31C. La figura 35 muestra la cinta usada.

Contenedor de agua

Microbomba

Manguera

Conexiones

Boquillas nebulizadoras

81

Figura 35. Cinta de LEDs usada para la interacción de luz

● Temperatura: se emplearon x2 placas peltier de 12V y 6A modelo 12706, unida cada una a x1 disipador de calor metálico a cada lado, y a x1 ventilador del lado usado para generar la sensación deseada (frío o calor), como se muestra en la figura 36.

Figura 36. Distribución de la estructura del módulo de temperatura

Ventilador Placa Peltier

Disipadores

82

6.3.2.2. Bill of materials (BOM). A partir de los métodos propuestos, el cuadro 10 muestra la lista de componentes necesarios para la construcción del objeto físico del módulo sensorial. Cuadro 10. BOM

Macro elemento

Micro elemento

Cantidad Función Material Proveedor Costo Unitario

Costo Total

Módulo de agua

Manguera con orificios

50cm Transportar el agua

Plástico Homecen-ter

$11000

$25100

Microbomba sumergible

1 Bombear el agua desde el recipiente

Plástico Tienda de electrónica online

$10000

Transistor TIP31C

1 Cerrar el circuito para encender la microbomba

Silicio Tienda de electrónica online

$600

Paquete de mini aspersores (x100). (Sólo se necesitan 6).

1 Nebulizar el agua bombeada al salir por la manguera

Plástico Tienda de electrónica online

$3500

Módulo de humo

Humidificador ultrasónico

1 Producir humo

Acero inoxidable

Tienda de electrónica online

$70000

$75000 Relé de 1 canal

1 Cerrar el circuito para encender el humidificador

Cobre Tienda de electrónica online

$5000

Módulo de luces

Cinta de LEDs RGB

50cm Encender luces de color

Plástico Tienda de electrónica online

$10000

$11800

Transistor TIP31C

3 Controlar el color de cada canal

Silicio Tienda de electrónica online

$600

Módulo de temperatura

Celda Peltier 2 Generar variación en la temperatura superficial

Silicio Tienda de electrónica online

$10300

$47600

83

Cuadro 10. (Continuación)

Macro elemento

Micro elemento

Cantidad Función Material Proveedor Costo Unitario

Costo Total

Módulo de temperatura

Ventilador 2 Expandir la “temperatura” al entorno cercano

Plástico Tienda de electrónica online

$6400

$47600 Disipador 2 Transportar

la temperatura

fuera de la celda

Aluminio Tienda de electrónica online

$7100

Módulo de viento

Ventilador 3 Generar viento

Plástico Tienda de electrónica online

$6400 $19200

Sistema de control

Arduino Mega

1 Controlar la lógica del sistema

Microcon-trolador

Tienda de electrónica online

$45000

$66000

Paquete de jumpers (x20)

3 Conectar actuadores con Arduino

Estaño Tienda de electrónica online

$7000

Empaque

Lámina de acrílico

1 Empaquetar y proteger el sistema

Acrílico Homecen-ter

$79900

$119800 Pegante universal

1 Fijar el empaque

Silicona Homecent-er

$29900

Tacos de madera

4 Estructurar y dar soporte

Madera Homecen-ter

$2500

TOTAL $364,500.00

Finalmente, analizando el sistema terminado, se estructuró el diagrama de caja transparente con las subfunciones definidas a partir los métodos para producir cada tipo de interacción sensorial. La figura 37 muestra el resultado obtenido.

84

Figura 37. Diagrama de caja transparente del módulo sensorial

85

6.3.3 Firmware. Para el desarrollo del firmware se aludió de nuevo al objetivo de mantener todo el código escrito en JavaScript. Para esto, se decidió integrar la librería Johnny-Five por la facilidad de implementar su API en el código del servidor previamente desarrollado. Como protocolo de comunicación con el microcontrolador o System on Chip (SoC), Johnny-Five implementa el estándar Firmata, lo que permite, finalmente, controlar el hardware desde código en JavaScript. Así, inicialmente se procedió a diseñar una función que detectara el evento sense enviado desde el player para determinar el tiempo de aparición y el tipo de las diferentes interacciones físicas a desplegarse. Desde esta función se realizarían llamados a otras 5 funciones creadas para manejar los datos distintivos de cada tipo de interacción y responder acordemente en el entorno real. Estas funciones, básicamente, leerán los pines definidos para ejecutar cada interacción y accionarán los estados high y low dependiendo del momento en el que deban iniciarse y detenerse, a diferencia de la función para controlar el módulo de luz en la que se debe generar una salida PWM por cada canal del modelo RGB para desplegar el color adecuado. Johnny-Five permite ejecutar estos comandos de manera sencilla. Por otro lado, como plataforma física para controlar los componentes electrónicos anteriormente descritos, se analizaron las principales opciones disponibles bajo los dos modelos de CPU pertinentes: microcontrolador a través de un Arduino Mega, y SoC a través de una Raspberry Pi 3 Model B. Ambas plataformas permiten la conexión de los diferentes actuadores requeridos para el módulo sensorial, por lo cual se concluyó que a nivel funcional son idénticos. Sin embargo, analizando a nivel no funcional, se determinó que el Arduino Mega era una mejor opción como placa de desarrollo por las siguientes razones: ● Al ser un microcontrolador es más sencillo de comenzar a utilizarse pues no requiere ningún tipo de instalación o configuración previa a su uso. ● Considerando el contexto de uso y a los estudiantes de Video y Televisión Digital como usuarios, se llegó a la conclusión de que es más probable que ya hayan tenido contacto con un Arduino durante la asignatura de Computación Física, que con una Raspberry Pi.

86

● De nuevo, con base en el contexto de uso, la Universidad cuenta con más Arduinos que Raspberry Pi’s. Considerando que el código fue desarrollado a través de Johnny-Five y Firmata, la única desventaja que se identificó frente a una Raspberry Pi fue la inhabilidad de cargarlo directamente a la placa. Así, el Arduino debe estar constantemente ligado a una máquina host, ya sea por USB o inalámbricamente (Bluetooth, WiFi, etc.), que ejecute el código y finalmente envíe las instrucciones al microcontrolador. Este inconveniente también implica que el software del servidor, encargado de trabajar tanto de medio de comunicación como de procesamiento y transmisión de interacciones al microcontrolador, deberá ejecutarse en el mismo equipo en el que se realiza la visualización de la plataforma social y player interactivo. Finalmente, se procedería a cargar el sketch de ejemplo “StandardFirmata” que se incluye de manera predeterminada en el IDE de Arduino para configurar el microcontrolador de tal manera que pueda leer las instrucciones recibidas por USB, el cual será el canal físico de conexión al equipo host usado en este proyecto. 6.3.4. Modelo prototipo preliminar del objeto físico. Una vez definidos la plataforma de desarrollo en software y hardware del módulo sensorial, la arquitectura, el medio de comunicación, y el software del frontend, se procedió a desarrollar un prototipo preliminar del objeto físico a modo de exploración y valoración de la dificultad en la implementación de los 5 tipos de interacciones sensoriales, por lo cual no se tuvieron en cuenta los requerimientos no funcionales RNF_19 y RNF_21. En este sentido, se realizó un boceto de la propuesta preliminar, el cual se puede encontrar en la figura 38. La estructura principal se construyó con cartón paja para facilitar su manipulación y disminuir el tiempo total de implementación. Posteriormente, se procedió a ensamblar cada uno de los módulos para las interacciones sensoriales de acuerdo a los procesos descritos anteriormente. La figura 39 muestra la versión final del dispositivo preliminar.

87

Figura 38. Boceto del prototipo preliminar del objeto físico

Figura 39. Objeto físico preliminar

Cabe destacar que para el módulo de humo de este primer prototipo, el humidificador permitía generar vapor de agua fácilmente pues no era necesario modificar sus componentes originales ni conectar otros o hacer uso de sustancias especiales, ya que funcionaba simplemente introduciéndose en un recipiente con agua. Sin embargo, debido a fallas de diseño, esta opción no pudo ser validada de manera correcta en vista de que no se encontró una forma eficiente para integrar

Luces

Temperatura

Agua

Viento

Extractor de humo

Arduino

Recipiente con agua

Conexión USB

88

este sistema dentro de la estructura y al mismo tiempo ventilar el vapor hacia el exterior pues los lapsos de tiempo en el que se producían estas interacciones eran muy cortos y la distancia que debía recorrer era muy larga como para realizar este proceso de manera adecuada. 6.3.5. Modelo de estudio del objeto físico final. Después de comprobar la factibilidad de los métodos propuestos para la generación de todas las interacciones sensoriales, se procedió a diseñar una nueva estructura contenedora, esta vez considerando todos los requerimientos no funcionales del sistema. Así, en las figuras 40 y 41 se muestran el boceto y la construcción de la versión inicial del diseño final propuesto a usarse para las pruebas de concept testing. Figura 40. Boceto del modelo de estudio del objeto físico

Este fue el modelo inicial usado para las pruebas con usuarios durante la socialización descrita en la siguiente sección del presente capítulo.

Contenedor de agua

Espacio para portátil

89

Figura 41. Modelo de estudio del objeto físico

6.3.6. Concept testing del módulo sensorial. El objeto físico del módulo sensorial no contempla un canal de retorno a la acciones que éste genera pues la interfaz del player y plataforma social son los encargados de este proceso. En este sentido, teniendo en cuenta que el usuario sólo interactúa con él en el sentido de percibir su contenido, se realizará sólo una evaluación de concepto en vista de la inexistencia de actividades que el usuario pueda realizar. Este proceso se llevó a cabo después de diseñarse y construirse el modelo de estudio anterior.

El objetivo de esta prueba es recibir feedback sobre el diseño propuesto y los requerimientos no funcionales del sistema sensorial en general. A partir de las sugerencias y opiniones obtenidas se analizarán las características que deberá tener el objeto físico, tales como materiales, medidas, y ubicación de elementos. El resultado de este proceso se presentará como modificaciones al BOM y boceto propuestos. Finalmente, se construirá el modelo prototipo final con los materiales y componentes estructurales definidos.

Este proceso se realizará con 5 estudiantes de la asignatura de Video y Televisión Digital en el InfoLab durante una sesión de clase. Se estima que el tiempo para completarlo será de aproximadamente 15 minutos distribuidos entre presentación general del proyecto y dispositivo, y discusión posterior.

90

Así, de la aplicación del concept testing surgieron tres aspectos principales a considerar para el objeto físico del módulo sensorial, específicamente en cuanto a la distribución y disposición de los componentes: ● Con el fin de mejorar la percepción de las interacciones físicas de viento, se debería analizar la posibilidad de integrar rejillas de ángulo graduable para los ventiladores; o eliminar el lado donde éstos se encuentran actualmente, y reubicarlos sobre una extensión del lado en diagonal donde ahora se ubican los aspersores de agua. ● Analizar la seguridad estructural del dispositivo frente al calor generado por el computador y la ubicación del contenedor de agua. ● Cambiar el espacio por donde saldría el humo generado por esta interacción física, moviéndolo desde el frente del dispositivo hacia la parte trasera, de tal forma que el humo no interrumpa la visualización del video. Igualmente, se socializaron los materiales y elementos electrónicos que se pensaban usar, obteniendo una retroalimentación positiva del BOM, lo cual implicó la no modificación de los componentes propuestos. Después de analizar la posible integración de estas características en el diseño propuesto, se tomó la decisión de no tener en cuenta ni la primera ni la tercera, en vista de que la implementación de estos cambios comprometería otros requerimientos y generaría una mayor complejidad para su construcción y distribución interna de componentes electrónicos. 6.3.7. Primer modelo prototipo del objeto físico final. Finalmente, luego de validar el diseño final propuesto, se empleó la cortadora láser disponible en el FABLAB para cortar las piezas en las formas necesarias de la lámina de acrílico original. La figura 42 muestra el modelo prototipo con la electrónica integrada.

91

Figura 42. Modelo prototipo del objeto físico final

6.4. VALIDACIÓN Y MEJORAS Ya habiendo desarrollado un primer modelo prototipo de todo el sistema, durante esta etapa se procede a realizar las pruebas de usabilidad con usuarios reales en contexto a través de la manipulación de las interfaces del sistema virtual. Éstas fueron almacenadas para su posterior análisis pues el proceso iterativo reiniciará desde este punto al detectarse los diversos problemas presentes en el sistema. El almacenamiento se realizó en forma de videos con audio previa notificación y autorización de los participantes. Igualmente, fueron realizadas en campo en el salón asignado para las clases. Específicamente se realizaron 5 tipos de pruebas durante todo el proceso de evaluación de usabilidad, orientados a la indagación acerca de los usuarios y a la valoración de cada uno de los componentes del sistema a lo largo de diferentes etapas del proyecto. La figura 43 muestra el proceso realizado. Al ser un proceso iterativo, los resultados preliminares de cada prueba en las dos iteraciones se presentarán bajo una sola sección, pero las modificaciones resultantes de la primera iteración, usados para evaluar durante la segunda y a los que se hará referencia en éstos, se presentarán finalmente en la sección 6.4.5.

92

Figura 43. Proceso de evaluación con usuarios

6.4.1.2. Versión final del modelo prototipo del objeto físico. Después de evidenciar nuevas falencias en el diseño final creado, se optó por buscar la asesoría del docente Edgar Martínez del programa de Diseño Industrial. Se socializaron los inconvenientes y se llegó a la definición de cambios específicos a implementar, que a continuación se detallan. ● El contenedor para agua resultó ser demasiado grande, generando un peso que no podía soportarse con la estructura actual; además de presentar filtraciones entre las paredes, lo cual podía terminar afectando los componentes electrónicos. Igualmente, no contaba con un sistema para extraer el agua una vez ingresada en caso de que quedaran residuos luego del uso del sistema. En este sentido, se optó por crear un recipiente más pequeño con una base de madera adherida a la base de la estructura, y con un agujero al lado de la estructura principal que se taparía por medio de un corcho. ● La estructura principal tampoco contaba con el soporte suficiente para sostener una computadora portátil en la parte superior como se planteó. Se decidió entonces usar también tacos de madera en diferentes puntos de su interior.

Experimentos formales

A. ------- B. -------------- C. -------

Encuesta Concept testing

SUS Entrevista

Iteraciones

93

● En cuanto a estética, se decidió posicionar los ventiladores frontales en el interior de la estructura y agregar un angeo blanco para ocultarlos a simple vista. Así, las figuras 44 y 45 muestran el proceso de implementación de algunos cambios, y la versión final del objeto físico que cumple con todos los requerimientos funcionales y no funcionales planteados. Figura 44. Principales modificaciones al objeto físico

Figura 45. Versión final del objeto físico

94

6.4.2. Experimentos formales del player y plataforma web social. La evaluación de usabilidad de estos dos módulos se realizó de manera paralela debido a que el player se encuentra integrado dentro de la plataforma social. Así, se llevó a cabo una serie de experimentos formales para los componentes principales de este sistema. Con base en los objetivos de uso de los usuarios, se determinó que estos componentes son: las interfaces comunes de la plataforma, la interfaz de la página de un video con sus componentes sociales, la interfaz y controles del player interactivo, y las interacciones en sí mismas que permitan al usuario modificar el playback o el contenido visualizado. Como instrumento para estas pruebas se usó una computadora portátil Macbook Pro de 13’’, de tamano similar a las disponibles por solicitud en el entorno inmediato al salón de clases, y el navegador web Google Chrome en su versión 63.0.3239.84. Al igual que con el concept testing, este proceso se realizó con 5 estudiantes a lo largo de 2 iteraciones con personas distintas en cada una. Así, se espera que con un total de 10 personas se encuentre, al menos, el 90% de los problemas de usabilidad.34 En cuanto al contenido del video presentado, se utilizó un video aleatorio corto con alrededor de 1-2 minutos de duración, tomado de Internet, al que se le agregaron todos los tipos de interacción disponibles tanto virtuales como físicos, mediante la creación manual de un archivo JSON como se describe en la sección 6.2.2.1. Este es el proceso que un usuario del sistema debe seguir para dotar de interactividad a su video. Sin embargo, cabe resaltar que esta interactividad no presentaba ningún sentido, sincronización, o información lógica respecto a lo que se mostraba en el video debido a que el objeto de análisis era el usuario y su interacción con el contenido, mas no el contenido en sí mismo, por lo cual no se consideró importante invertir tiempo en la creación de un video interactivo que tuviera sentido. 6.4.2.1. Lista de actividades. Las actividades propuestas se orientan a la evaluación de las interacciones requeridas para completar los objetivos principales del usuario con el uso del sistema, a través de su interfaz gráfica. El cuadro 11, presentado a continuación, detalla las pruebas realizadas, las tareas que el usuario debió ejecutar, y los objetivos de su realización. _______________________ 34 NIELSEN, Jakob. Why You Only Need to Test with 5 Users [en linea]. Nngroup.com. (19 de marzo del 2000). [Consultado: 16 de julio de 2018]. Disponible en Internet: https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/

95

Cuadro 11. Lista de experimentos formales

Componente a evaluar

# Escenario Tareas

involucradas Objetivos de la

prueba

Interfaces de la plataforma

social

1 “Te interesa la plataforma y quieres crear una cuenta de usuario”

Encontrar la opción para registrarse en la plataforma, navegando hasta el menú principal.

- Determinar la facilidad de acceso a esta opción.

2 “Quieres cambiar el idioma a espanol”

Encontrar la opción para cambiar el idioma de la interfaz.

- Determinar la facilidad de acceso a esta opción.

3 “Abriste por primera vez la página. Visualiza el único video que se encuentra disponible”

Identificar y reproducir un video haciendo click sobre su thumbnail.

- Determinar si la distribución del layout prioriza la visualización general de videos disponibles. - Determinar si es claro que el thumbnail de un video actúa como link.

4 “Intentas volver a buscar el nombre del video desde esta pagina”

Identificar la barra de búsqueda.

- Determinar si su ubicación es apropiada.

5 “Ya tienes una cuenta y ahora quieres subir un video”

Encontrar la opción para subir un nuevo video desde el menú principal.

- Analizar el proceso de carga de un nuevo video y su asociación con un archivo de interacciones.

96

Cuadro 11. (Continuación)

Componente a evaluar

# Escenario Tareas

involucradas Objetivos de la

prueba

Interfaz del player

6 “Intenta pausar y volver a reproducir el video”

Hacer click en el ícono correspondiente de la barra de controles; dar click sobre el video; o presionar spacebar.

- Determinar si cualquiera de los 3 métodos para realizar esta acción es reconocible y fácilmente accesible.

7 “Quieres mantener el video reproduciendo. Ponlo en modo loop”

Hacer click sobre el ícono de correspondiente.

- Determinar si la ubicación e iconografía son apropiados.

8 “Quieres ver el video en pantalla completa. Ponlo en modo fullscreen”

Hacer click sobre el ícono de correspondiente.

- Determinar si la ubicación e iconografía son apropiados.

9 “Quieres ver todo el video rápidamente. Aumenta la velocidad de reproduccion”

Hacer click sobre los íconos correspondientes.

- Determinar si la ubicación e iconografía son apropiados.

10 “El video tiene un audio muy molesto. Ponlo en modo mute”

Hacer click sobre el ícono correspondiente o ajustar el slider.

- Determinar si la ubicación e iconografía son apropiados.

11 “No puedes visualizar bien el video. Modifica las opciones (brillo, contraste, etc.)”.

Encontrar el ícono de los filtros y modificar los valores de los sliders correspondientes.

- Determinar si la ubicación e iconografía son apropiados.

97

Cuadro 11. (Continuación)

Componente a evaluar

# Escenario Tareas

involucradas Objetivos de la

prueba

Interacciones

12 “Quieres ver una sección distinta del video a la actual. Intenta saltar a otra”

Hacer click sobre los hotspots marcados correspondientemente.

- Determinar si la interacción por medio de clicks es clara.

13 “Quieres volver a otra sección del video y ver un resumen general de todas”

Identificar el botón de interacciones tipo index.

- Determinar si la posición e iconografía son apropiados.

14 “Quieres expandir la información sobre alguno de los temas mostrados. Abre un link externo”

Hacer click sobre alguno de los links externos.

- Determinar si la interacción por medio de clicks es clara.

Interfaz de la página de un

video

15 “Quieres dar tu opinión dejando un comentario en el video”

Identificar el área de texto disponible para escribir un comentario.

- Determinar si la ubicación del módulo de comentarios es adecuada, y el método de envío es claro.

16 “Quieres compartir el video con un amigo”

Identificar la sección y opciones para compartir el video.

- Determinar si la ubicación e iconografía del módulo social son apropiados, y las opciones disponibles son claras.

17 “Te gusto el video y quieres dejar una calificación positiva”

Identificar los íconos de like y dislike

- Determinar si la ubicación e iconografía son apropiados.

98

Cuadro 11. (Continuación)

Componente a evaluar

# Escenario Tareas

involucradas Objetivos de la

prueba

Interfaz de la página de un

video

18 “Te quieres suscribir al canal del autor del video”

Identificar el botón de suscripción al canal.

- Determinar si la ubicación y estilo del botón son apropiados.

6.4.2.2. Métricas evaluadas. Básicamente se evaluaron 3 categorías de métricas: error, éxito, y tiempo. Debido a que se esperaba que la mayoría de las actividades se realizaran en unos pocos segundos al ser interacciones que no requerían navegar a otras interfaces, las dos primeras métricas se analizaron para todas las actividades, mientras que el tiempo sólo se tuvo en cuenta para aquellas que eran más complejas y en las que se estimó que el usuario iba a tener mayores dificultades; es decir, esta métrica sólo se analizó para los escenarios #1 y #5. La lista de todas las métricas evaluadas se presenta a continuación en el cuadro 12, junto a su objetivo del análisis. Cuadro 12. Lista de métricas evaluadas

Categoría Métrica Objetivo del análisis

Error (%)

Error crítico

- Determinar cuáles son las actividades que presentan problemas que evitan su consecución total.

Error no crítico - Determinar cuáles son las actividades con problemas menores.

Error total (error crítico + no

crítico)

- Obtener un vistazo general de la usabilidad del sistema. - Comparar su proporción frente al porcentaje de éxito total.

Éxito (%) Éxito sin errores - Determinar cuáles actividades no presentan problemas.

99

Cuadro 12. (Continuación)

Categoría Métrica Objetivo del análisis

Éxito (%) Éxito total

(éxito sin errores + error no crítico)

- Obtener un vistazo general de la usabilidad del sistema. - Comparar su proporción frente al porcentaje de error total.

Tiempo (s) Tiempo de ejecución

total

- Determinar cuán confuso puede llegar a ser el proceso como para tardar un tiempo considerable.

Al igual que el tratamiento dado a los resultados de las primeras encuestas en la etapa de análisis de usuarios, se graficaron los resultados de cada métrica con cada actividad, y con base en la totalidad de participantes se presentaron porcentajes globales que permitieron identificar los grados de severidad en los casos hallados con problemas en el sistema. En conjunto con las respuestas de la entrevista post-test (ver Anexo G para el guion de preguntas), se pudo determinar las características de los problemas presentados. Las sesiones fueron grabadas en audio y video a través de la aplicación lookback en su versión de prueba gratuita; la figura 46 muestra un ejemplo del entorno en el que se desarrollaron. En las siguientes secciones del presente capítulo se describen los resultados encontrados en cada fase de evaluación, finalizando con un resumen de las mejoras implementadas con base en ellos. Luego de realizar la primera iteración de la secuencia experimentos formales, SUS, y entrevistas; las figuras 47 y 48 muestran los resultados de las actividades llevadas a cabo por cada usuario. Así, se identifica que el porcentaje de éxito total, equivalente al éxito sin errores más error no crítico, es del 93.3% versus un 6.7% de error crítico, lo cual indica que de manera general la gran mayoría de los usuarios logró completar las tareas asociadas a la realización de cada actividad.

100

Figura 46. Ejemplo del entorno de desarrollo de los experimentos formales a través de la aplicación lookback

El cálculo de estos porcentajes se realizó mediante una regla de tres simple, con base en el desempeño de los usuarios en la totalidad de escenarios de los experimentos formales. A continuación, se presenta el ejemplo del cálculo realizado para obtener la figura 48 con base en los resultados de la figura 47.

É𝑥𝑖𝑡𝑜 𝑡𝑜𝑡𝑎𝑙 𝑝𝑎𝑟𝑎 𝑡𝑜𝑑𝑎𝑠 𝑙𝑎𝑠 𝑝𝑟𝑢𝑒𝑏𝑎𝑠 = 84 𝑢𝑠𝑢𝑎𝑟𝑖𝑜𝑠

𝐸𝑟𝑟𝑜𝑟 𝑐𝑟í𝑡𝑖𝑐𝑜 𝑝𝑎𝑟𝑎 𝑡𝑜𝑑𝑎𝑠 𝑙𝑎𝑠 𝑝𝑟𝑢𝑒𝑏𝑎𝑠 = 6 𝑢𝑠𝑢𝑎𝑟𝑖𝑜𝑠 𝑇𝑜𝑡𝑎𝑙 "𝑢𝑠𝑢𝑎𝑟𝑖𝑜𝑠" 𝑝𝑎𝑟𝑎 𝑡𝑜𝑑𝑎𝑠 𝑙𝑎𝑠 𝑝𝑟𝑢𝑒𝑏𝑎𝑠 = 90 𝑢𝑠𝑢𝑎𝑟𝑖𝑜𝑠

90 𝑢𝑠𝑢𝑎𝑟𝑖𝑜𝑠

100%=

84 𝑢𝑠𝑢𝑎𝑟𝑖𝑜𝑠

𝑋

𝑋 = 93.333% 𝑑𝑒 é𝑥𝑖𝑡𝑜 𝑡𝑜𝑡𝑎𝑙

90 𝑢𝑠𝑢𝑎𝑟𝑖𝑜𝑠

100%=

6 𝑢𝑠𝑢𝑎𝑟𝑖𝑜𝑠

𝑌

𝑌 = 6.667% 𝑑𝑒 𝑒𝑟𝑟𝑜𝑟 𝑐𝑟í𝑡𝑖𝑐𝑜

101

Figura 47. Resultados de actividades completadas en la primera iteración

Figura 48. Porcentajes de éxito total versus error crítico en la primera iteración

Los escenarios donde se presentaron dificultades que no permitieron su consecución exitosa fueron los números 4, 9, 11 y 13. En el cuadro 13 se describen algunas observaciones que se presentaron durante el proceso de desarrollo de cada una, de las cuales algunas fueron obtenidas de las respuestas de la entrevista post-test, como se planeó.

102

Cuadro 13. Análisis de actividades con error crítico en la primera iteración

# Escenario Usuarios afectados

4

“Intentas volver a buscar el nombre del video desde esta pagina”

1

Observaciones Recomendaciones

El usuario creyó que el mismo video volvería a aparecer en la interfaz del sistema, cuando en realidad se pretendía que hiciera uso de la barra de búsqueda. Fue un error en el planteamiento del escenario que se presentó con el primer usuario que realizó la prueba y, por lo tanto, fue aclarado para pruebas siguientes sin revelar detalles de las tareas involucradas. La inexistencia de más usuarios afectados da cuenta de esto.

- Nada en particular.

# Escenario Usuarios afectados

9

“Quieres ver todo el video rapidamente. Aumenta la velocidad de reproduccion”

1

Observaciones Recomendaciones

El usuario confundió la iconografía usada con botones para cambiar de video a modo de playlist.

- Reemplazar los íconos usados.

103

Cuadro 13. (Continuación)

# Escenario Usuarios afectados

11

“No puedes visualizar bien el video. Modifica las opciones (brillo, contraste, etc.)”

2

Observaciones Recomendaciones

Los usuarios no distinguieron los íconos para accionar las opciones correspondientes, debido tanto a la opacidad usada como a la posición en la que están ubicados. Además, debido a las interacciones de prueba empleadas, algunas ocultaban los controles, lo cual dificultó aún más su percepción. Sin embargo, los usuarios que no tuvieron dificultad expresaron que la iconografía empleada es pertinente.

- Aumentar la opacidad de los botones. - Cambiarlos de posición. - Cambiar su color dependiendo de los colores que se estén mostrando en el video. - Reemplazarlos por un menú activado con click derecho. - Limitar el área de aparición de las interacciones visuales de tal forma que no se solapen con los controles de la interfaz.

# Escenario Usuarios afectados

13

“Quieres volver a otra seccion del video y ver un resumen general de todas”

2

Observaciones Recomendaciones

Debido a que esta opción se acciona de la misma manera que la actividad #11, los mismos 2 usuarios presentaron los mismos inconvenientes.

- Las mismas del escenario #11.

104

Por otro lado, el cuadro 14 muestra el tiempo que cada usuario tardó en realizar los escenarios #1 y #5, correspondientes a la creación de una cuenta y a la carga de un nuevo video respectivamente. Cuadro 14. Tiempos de terminación para las actividades #1 y #5 en la primera iteración

Usuario Tiempo actividad #1 (s) Tiempo actividad #5 (s)

1 55 65

2 50 45

3 58 97

4 50 60

5 47 30

Promedio 41 40

No se presentaron inconvenientes mayores durante la actividad #1. Sin embargo, después de crear la cuenta de usuario el sistema no realiza el login automáticamente, por lo que para llevar a cabo la actividad #5, la plataforma requería que los usuarios realizaran este proceso, lo cual resultó confuso para todos. Además, la única tarea asociada a esta última actividad sólo consistía en encontrar y hacer click en el botón correspondiente; mientras que para la primera era necesario realizar estos mismos pasos, además de navegar desde la pantalla de login hasta la de registro y llenar la información correspondiente, proceso en el que sólo algunos usuarios tuvieron dificultades. En este sentido, se esperaba que el tiempo promedio de la actividad #5 hubiera sido considerablemente menor al de la actividad #1. Sin embargo, debido a que este problema no se relaciona directamente con el sistema de videos interactivos desarrollado, sino que es más bien intrínseco al funcionamiento de la plataforma (YouPHPTube), no se consideró como un punto de mejora de alta prioridad para la segunda iteración. Sin embargo, se realizó una prueba de referencia posterior con un nuevo usuario, que aunque no hace parte del público objetivo, sí cuenta con experiencia en diseño y evaluación de GUIs; a quien se le mostró la interfaz en dos fases: un

105

primer contacto controlado en el que reconoció de manera general los principales elementos de la interfaz mientras era presentada por el autor del proyecto, pero sin mostrar claramente la forma de realizar estas dos actividades; y un segundo contacto, realizado aproximadamente 20 horas después, en el que se evaluaron estas mismas actividades, obteniendo los resultados del cuadro 15. Las condiciones en las que se realizaron ambos acercamientos fueron las mismas de las pruebas realizadas para el concept testing y los experimentos formales, a excepción del espacio geográfico que esta vez fue un cuarto sin ruido externo, por fuera de la Universidad. Cuadro 15. Referencia de tiempos de terminación para las actividades #1 y #5 con un usuario experimentado.

Usuarios NO experimentados

Usuario experimentado

Tiempo actividad #1 (s) 41 10

Tiempo actividad #5 (s) 40 22

En este sentido, la diferencia existente entre el promedio de los usuarios no experimentados versus el experimentado es considerable. Esto indica que el sistema no es “asimilable” en terminos de la facilidad para aprender a usar su interfaz, al menos para estas dos actividades. Se debe, entonces, considerar a futuro como parte de mejoras a la interfaz de la plataforma social base, la implementación de cambios encaminados a aumentar la visibilidad de los vínculos que redirigen al usuario hacia las interfaces correspondientes de cada actividad, donde el proceso que deben seguir ya es más claro, como se pudo evidenciar durante la ejecución de los experimentos formales. Luego, para la segunda ronda de pruebas, realizada bajo las mismas condiciones que la primera (cantidad de usuarios, lugar, implementos y herramientas), y después de aplicar algunas mejoras con base en lo encontrado, se presentaron menos inconvenientes, situación reflejada en las figuras 49 y 50. De manera general se puede observar una disminución del porcentaje de error crítico en un 2.3%. Ahora, analizando las actividades que presentaron dificultades en la primera iteración, también se puede evidenciar una disminución considerable en los errores durante las actividades #11 y #13, pasando en el número de usuarios afectados desde 2 y 2 a 0 y 1, respectivamente.

106

Figura 49. Resultados de actividades completadas en la segunda iteración

Figura 50. Porcentajes de éxito total versus error crítico en la segunda iteración

Por otro lado, cabe resaltar que se presentaron errores críticos y no críticos en nuevas actividades: #7 y #12. Las tareas involucradas para éstas implicaban la ubicación y reconocimiento de íconos. El hecho de que este tipo específico de inconvenientes se de esporádicamente a lo largo de varias actividades en distintas

107

ocasiones y con nuevos usuarios, podría entenderse como parte del proceso natural de aprendizaje de un nuevo sistema y no como una falencia mayor. En cuanto a los tiempos medidos para las actividades #1 y #5, no se observó un cambio significativo teniendo en cuenta que para la primera no se implementó ninguna mejora; mientras que para la segunda el cambio se implementó, mediante la adición de un nuevo botón más visible, después de aplicada la segunda iteración de pruebas. En este sentido, no se muestran los nuevos datos; y su relación con la prueba de referencia también sigue siendo la misma. 6.4.3. Escala de Usabilidad del Sistema (SUS). Posterior a la realización de los experimentos formales, se aplicará el cuestionario de 10 ítems del SUS con cada

uno de los mismos usuarios (5) para ambas iteraciones (𝑁𝑠𝑢𝑠 = 10), cuyos resultados serán analizados mediante el proceso definido por la escala, obteniendo un valor de la percepción del sistema por cada uno. La plantilla usada se puede encontrar en el Anexo B. Cabe resaltar de nuevo que la cantidad de 5 usuarios es considerada como ideal según un estudio realizado por Jakob Nielsen, y referenciado anteriormente. Así, después de calcular los resultados de la aplicación del SUS correspondientes a la primera iteración, se obtuvo lo descrito en el cuadro 16. Cuadro 16. Resultado del SUS de la primera iteración

Número de usuarios Iteración Puntaje total

5 1 74

Teniendo en cuenta que el valor estándar para que la usabilidad de un sistema se considere por encima del promedio es de 68, el puntaje obtenido de 74 indica que, de manera general, la usabilidad del sistema no presenta inconvenientes que afecten la experiencia en gran medida, lo cual se sustenta con lo obtenido en la gráfica 2 anteriormente presentada. Sin embargo, se esperaría que el porcentaje de 93% debería ser correspondido por un mayor puntaje de SUS que 74. Esto implica que a pesar de que las tareas pudieron ser completadas con relativo éxito, aún existían mejoras que se podían realizar sobre la usabilidad del sistema como se describió anteriormente.

108

Luego de realizar las principales mejoras pertinentes, se volvió a aplicar este cuestionario con 5 estudiantes diferentes. Los cálculos arrojaron lo expuesto en el cuadro 17. Cuadro 17. Resultado del SUS de la segunda iteración

Número de usuarios Iteración Puntaje total

5 2 76.5

Los puntajes obtenidos de las dos iteraciones realizadas no muestran un incremento considerable a pesar de haber modificado las falencias principales encontradas, por lo que se esperaría un incremento en la facilidad de uso del sistema. Sin embargo, esta diferencia es proporcional al incremento en el porcentaje de éxito total, pasando de 93.3% a 95.6%, es decir, un incremento del 2.3%. Esto conlleva a pensar que los problemas que se siguen presentando podrían deberse a dos causas: o no han sido identificados aún; o son relacionados al sentimiento general que evoca la plataforma, es decir, aspectos como estética y diseño que van más allá de lo funcional y usable. La primera razón no tiene tanto sustento argumentativo frente a los porcentajes de error tanto crítico como no crítico, que serían aquellos usuarios que tuvieron problemas, pues también son muy bajos; además de lo expuesto por Jakob Nielsen en estudios pasados respecto a la cantidad de usuarios necesarios para realizar pruebas de usabilidad efectivas. Así, es factible que mejores resultados podrían ser obtenidos a partir de cambios gráficos en la interfaz de usuario tanto del player como de la plataforma web, así como del video interactivo de prueba empleado. Igualmente, desarrollar otro tipo de pruebas como evaluaciones heurísticas podrían brindar una visión más amplia frente a este problema. 6.4.4. Entrevista de satisfacción general post-test. Finalizando la secuencia de evaluación iterativa, como sugerencias y observaciones adicionales durante las entrevistas post-test se obtuvo comentarios muy similares en ambas iteraciones, presentándose en mayor medida los siguientes:

109

● Las interfaces son parecidas a YouTube, especialmente la página de un video. ● Las características de la plataforma están bien integradas y funcionan correctamente. ● Analizar la implementación de un tutorial inicial. ● La opacidad de los controles de playback no incomoda al usuario. ● Incluir doble click como medio para activar el modo fullscreen. ● Incluir un botón para subir un video en la barra principal, de tal forma que se asimile más a YouTube y esta opción sea más fácilmente accesible. ● No se entendió el por qué era necesario hacer login justo después de registrarse en la plataforma. 6.4.5. Implementación de mejoras al sistema. A partir del feedback recibido en la primera iteración, sólo se implementaron 3 cambios visuales principales para las interfaces gráficas del player y plataforma web en vista de que no existieron muchos problemas. A continuación, se describen. ● Se agregó un botón para cargar un nuevo video directamente en la barra principal al lado izquierdo del menú desplegable de selección de idioma, como se muestra en la figura 51. De esta forma se facilita su ubicación pues ya no se encuentra oculto en el menú desplegable principal. Figura 51. Botón para cargar un video

● Se aumentó la opacidad de los botones laterales para aplicar filtros y abrir el menú correspondiente a la interacción INDEX con el fin de aumentar su visibilidad; mostrado en la figura 52.

110

Figura 52. Botones laterales con mayor opacidad

● Uno de los mayores inconvenientes fue la confusión de los íconos para aumentar y disminuir la velocidad de reproducción con la funcionalidad para cambiarlo al anterior y siguiente. En este sentido, se implementaron nuevos íconos, mostrados en la figura 53. Figura 53. Nuevos íconos preliminares para cambiar la velocidad de reproducción del video

Sin embargo, aún se debe trabajar en la integración con la estética general de los demás íconos.

111

7. CONCLUSIONES Considerando el desarrollo del sistema que permite la integración de interactividad a videos tradicionales por medio del archivo JSON descrito, se cumple con el objetivo general planteado de “Desarrollar una plataforma de Video y Television Digital que permita a los estudiantes de Ingeniería Multimedia que cursan esta asignatura la inclusion de interactividad estandar y multisensorial en sus videos”, a través de la realización de un trabajo exploratorio presentado por medio de una implementación técnica fundamentada en un proceso de investigación mixta y enmarcado en la metodología de diseño centrado en el usuario, conllevando también a la ejecución de etapas de análisis, diseño y validación iterativa de requerimientos. Ahora bien, la elección de la metodología de diseño centrado en el usuario fue adecuada pues sus etapas se ajustaron correctamente a las particularidades inherentes y actividades asociadas a cada objetivo secundario planteado, distribuyendo la carga de trabajo correspondiente de manera coherente a lo largo del flujo que ésta propone. Además, su naturaleza iterativa propició la adquisición de feedback en etapas tempranas del desarrollo. Consecuentemente, también se facilitó la consecución del objetivo general. De esta forma, el desarrollo de este proyecto permitió poner en práctica e integrar diversos conocimientos y habilidades adquiridas a lo largo de la carrera, en especial aquellos relacionados a las asignaturas profesionales de Interacción Hombre-Máquina, Computación Física, Bases de Datos Multimedia, Video y Televisión Digital, y Redes y Servicios Multimedia. 7.1. CONTRIBUCIONES E IMPLICACIONES En este sentido, considerando las características de la población objetivo como tamaño, ubicación y disponibilidad de tiempo, la aplicación de encuestas como método de caracterización inicial facilitó la adquisición de los datos relevantes para el proyecto sin presentarse ninguna desventaja considerable frente a métodos de indagación presenciales. Igualmente, esto permitió la recolección de datos de tipo cuantitativo, necesarios en este formato para esta etapa preliminar de la metodología seguida. El análisis de los datos encontrados y la posterior creación de un perfil de usuario, una persona y un diagrama del contexto de uso, permitieron comprender la

112

relación entre la problemática identificada y las necesidades del usuario en el entorno correspondiente, específicamente a nivel educativo. Esto permitió la definición correcta de los requerimientos funcionales y no funcionales del sistema. Respecto a las mediciones realizadas es posible concluir que aunque el tamaño

total de la muestra no es aparentemente grande (𝑁𝑡𝑜𝑡𝑎𝑙 = 19) para realizar un análisis cuantitativo significativo, se ha demostrado en estudios anteriores la superioridad en cuanto a la relación costo-beneficio de realizar pruebas de usabilidad con pocos participantes a lo largo de varias iteraciones. Igualmente, de este proceso se encontró un hallazgo sorpresivo frente a la disposición de los usuarios a realizar pagos de hasta USD $20 para tener acceso a plataformas que les permitiera desarrollar sus proyectos con alguna ventaja frente a un desarrollo propio desde cero. Esto da cuenta y refuerza la necesidad de crear sistemas como el aquí desarrollado. Además, esto también indica que si este proyecto no fuera open source sino comercializado, podría llegar a generar ganancias considerables. La integración de la plataforma social YouPHPTube en su versión 3.0 significó una gran ayuda para implementar toda la arquitectura tanto frontend como backend requerida para montar un sistema de carga, almacenamiento, publicación y compartición de videos. Asimismo, al ser open source, la facilidad de modificación de su código fuente hizo de la integración con el player desarrollado un proceso relativamente sencillo. Del mismo modo, la comunicación en tiempo real del módulo virtual y sensorial se agilizó gracias a la integración de librerías como Socket.io, y el control del Arduino mediante Johnny-five. En este sentido, mantener todo el código principal en un solo lenguaje (JavaScript) facilitó el desarrollo en cuanto a que no se presentaron inconvenientes por incompatibilidad en la integración de los módulos. Gracias a la flexibilidad y enfoque agnóstico de esta plataforma en cuanto a un nicho de mercado, su integración y uso como parte fundamental del sistema plantea una nueva aproximación a las plataformas online actuales para videos interactivos. Al no orientarse a un objetivo o tipo de video específico, permitió dar cumplimiento al propósito de crear un entorno libre que sirviera como punto de partida para los tratamientos de contenidos deseados por cada usuario, sin dejar de lado las características funcionales básicas como compartición y sociabilidad, y administración de usuarios.

113

A nivel de hardware, el desarrollo de este proyecto significó la expansión del concepto de video interactivo actual, entrelazándose con la computación física y la interacción multisensorial, unión que no ha sido tratada en ningún ámbito de la literatura consultada. Asimismo, el desarrollo del módulo sensorial a nivel físico, de manufactura y empaquetado supuso un reto importante. Debido a la carencia de consideraciones especializadas y más minuciosas, así como de conocimientos generales y habilidades en fabricación, que son temas más íntimamente ligados a otro tipo de ingenierías y profesiones, se presentaron numerosos inconvenientes con el diseño originalmente planteado para el objeto físico que comprometían algunos requerimientos tanto funcionales como no funcionales. En este sentido, el tiempo, las sugerencias y la ayuda proveída por un docente del programa de Diseño Industrial fue fundamental para superar estos inconvenientes. Si se desean crear múltiples unidades del objeto físico aquí descrito por los mismos estudiantes, cabe resaltar entonces la posible necesidad de integrar una asignatura obligatoria (o como parte de una existente) del ciclo básico común de ingenierías, enfocada al desarrollo de competencias teóricas y prácticas en temas de prototipado y fabricación en general; puesto que, al menos durante los períodos 2013-2014, no se recibió formación considerable en estos ámbitos durante asignaturas como Introducción a la Ingeniería 1 y 2 ni en Diseño Conceptual, a excepción del uso de la cortadora láser. De manera consecuente, el sistema desarrollado se podría emplear como una aproximación a un sistema de Cine 4D, pero a nivel personal. A partir del análisis de más requerimientos en torno a este ámbito, se podría pensar en la integración de más interacciones sensoriales como olores y respuestas hápticas, así como una mejora en la ergonomía del diseño físico actual. Estos factores lo acercarían más a este objetivo. A nivel de software, el desarrollo del sistema basado completamente en tecnologías open source facilita no sólo la replicación de la plataforma, sino su personalización, extensión y mejoría. Asimismo, la versión del player optimizada para usarse como plugin permite su integración a sistemas por fuera de la plataforma social, de tal forma que esta facilidad fomenta su uso en proyectos más grandes que puedan hacer uso de videos interactivos multisensoriales, por ejemplo, para el área de diseño transmedia.

114

En cuanto a la evaluación de requerimientos, el proceso seguido para el análisis y recolección de feedback mediante cuatro tipos de pruebas: concept testing, e iteraciones de experimentos formales, SUS, y entrevistas post-test, permitió abarcar un amplio campo de opiniones y puntos de vista frente a los requerimientos funcionales y no funcionales de ambos módulos del sistema (virtual y físico) que aportaron a la completitud de los datos tenidos en cuenta tanto para plantear como para mejorar el desarrollo. En particular, el contenido y orden de aplicación de la secuencia iterativa permitió tanto diagnosticar las falencias puntuales del sistema (experimentos formales), como clasificarlo con base en su facilidad de uso (SUS), siendo ambas pruebas de resultados cuantitativos; para finalmente obtener datos cualitativos (entrevistas) que dieran una visión más personal a la investigación y mejorar el proyecto en función de esto. Por otro lado, dando continuidad al uso de videos interactivos con un alcance multisensorial en el ámbito educativo, se podría plantear a futuro un desarrollo más extenso de las características del sistema actual. De tal forma que se puedan generar y almacenar estadísticas de uso del sistema para cada usuario específico de la plataforma, tales como tiempo de visualización, participación con las interacciones virtuales presentadas (en términos de hizo click o no, por ejemplo), y la implementación de quizzes interactivos, entre otros. Asimismo, llevar a cabo otro experimento en torno a una investigación acerca de la utilidad del video interactivo versus otros métodos de aprendizaje en el contexto de una asignatura del programa de Ingeniería Multimedia sería interesante de considerar en vista de las particularidades tecnológicas de la carrera, las superposiciones de diversos saberes, y de las posibilidades que brinda la plataforma desarrollada tanto directamente como por medio de su API. Sin embargo, debe tenerse en cuenta que, en este sentido, sería muy importante la calidad del video producido en sí mismo en cuanto a estética y pertinencia del contenido presentado, como fue demostrado por los resultados de las pruebas. 7.2. LIMITACIONES Al corresponder a una primera aproximación a la problemática identificada, el alcance educativo práctico de la implementación del sistema producto del proyecto deberá ser convalidado por las instancias académicas correspondientes para efectos de su integración y uso continuo como herramienta de soporte en la Asignatura.

115

Igualmente, el desarrollo de la parte hardware del sistema representa no sólo una gran inversión temporal como se describió anteriormente, sino también un costo monetario muy significativo (≈ 𝐶𝑂𝑃 $364,500.00). Sin embargo, esto depende en gran medida de los materiales aquí propuestos (en especial los concernientes al empaquetamiento) que, a su vez, fueron determinados en función del diseño creado. En este sentido, pensar en un nuevo diseño podría disminuir los gastos asociados a todos los ámbitos del proceso. Finalmente, una limitación técnica importante del sistema actual es la concurrencia de usuarios de la plataforma web frente al funcionamiento del módulo sensorial. Teniendo en cuenta que sólo se desarrolló un objeto físico, actualmente no existe una forma de enlazar el video que un usuario esté visualizando con el objeto específico en uso; de tal forma que si dos usuarios visualizan dos videos distintos simultáneamente, se esperaría que el comportamiento de las interacciones sensoriales va a resultar en la combinación de ambos archivos JSON, aunque esto no se ha comprobado.

116

BIBLIOGRAFÍA

ATTRILL, Roger. Human Centered Design vs. User Centered Design [en línea]. StackExchange: User Experience. (23 de enero de 2015). [Consultado: 14 de octubre de 2017]. Disponible en Internet: https://ux.stackexchange.com/questions/72445/human-centered-design-vs-user-centered-design CASTRO BENAVIDES, David Alejandro. Presentaciones de clase de Diseño Multimedia (fases 1, 2, 3, y 4) [diapositivas]. Cali, Colombia. Periodo 2017-1. [Consultado: 14 de octubre de 2017]. Disponible directamente con el profesor a través del e-mail: dacastro@uao.edu.co. Cambridge Dictionary. framework [en línea]. Cambridge Dictionary. [Consultado: 15 de octubre de 2017]. Disponible en Internet: http://dictionary.cambridge.org/dictionary/english/framework Carnegie Mellon University Open Learning Initiative. Introduction to Psychology (Open + Free): Module 9 / Sensation and Perception [en línea]. Oli.cmu.edu. [Consultado: 15 de octubre de 2017]. Disponible en Internet: https://oli.cmu.edu/jcourse/workbook/activity/page?context=df3e70ea0a0001dc759a394265a80f9a Demand Metric. Interactive Video: Defining & Measuring Performance [diapositivas]. Brightcove.com. (Noviembre de 2015). [Consultado: 13 de octubre de 2017]. Disponible en Internet: http://files.brightcove.com/bc-demandmetric-interactive-video-benchmark-report.pdf GRANOLLERS, Toni. Modelo Mental y Modelo Conceptual [en línea]. Grihotools.udl.cat. [Consultado: 13 de octubre de 2017]. Disponible en Internet: http://www.grihotools.udl.cat/mpiua/fases-mpiua/diseno/modelo-mental-y-modelo-conceptual/ Isdi. Social TV como herramienta de marketing digital [en línea]. Isdi.education. [Consultado: 21 de julio de 2018]. Disponible en Internet: https://www.isdi.education/es/isdigital-now/social-tv-como-herramienta-de-marketing-digital

117

ISO/TC 159/SC 4. Human-centred design for interactive systems. En: ISO 9241-210:2010. 1 ed. p. 6. Joubel. Interactive Video [en línea]. H5p.com. (06 de octubre de 2013). [Consultado: 13 de octubre de 2017]. Disponible en Internet: https://h5p.org/interactive-video Liferay. Introduction to liferay development [en línea]. Dev.liferay.com. [Consultado: 13 de octubre de 2017]. Disponible en Internet: https://dev.liferay.com/es/develop/tutorials MEYER, Kate. The Characteristics of Minimalism in Web Design [en línea]. Nngroup.com. (12 de julio de 2015). [Consultado: 13 de octubre de 2017]. Disponible en Internet: https://www.nngroup.com/articles/characteristics-minimalism/ NIELSEN, Jakob. Why You Only Need to Test with 5 Users [en linea]. Nngroup.com. (19 de marzo del 2000). [Consultado: 16 de julio de 2018]. Disponible en Internet: https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/ NOVIELLO, Riccardo. What is the best site to learn Liferay? [en línea]. Quora.com. (18 de marzo de 2015). [Consultado: 13 de octubre de 2017]. Disponible en Internet: https://www.quora.com/What-is-the-best-site-to-learn-Liferay Open Source Initiative. Basics of Open Source: What is “Open Source” software? [en línea]. Opensource.com. [Consultado: 15 de octubre de 2017]. Disponible en Internet: https://opensource.org/faq#osd --------. The Open Source Definition [en línea]. Opensource.com. [Consultado: 15 de octubre de 2017]. Disponible en Internet: https://opensource.org/osd RIGSBY, Josette. Gartner's Magic Quadrant For Horizontal Portals: Oracle, IBM, Microsoft, SAP, Liferay Top Dogs [en línea]. Cmswire.com. (11 de octubre de 2012). [Consultado: 13 de octubre de 2017]. Disponible en Internet: https://goo.gl/EgKknz

118

RaptMedia. Product [en línea]. Raptmedia.com. [Consultado: 13 de octubre de 2017]. Disponible en Internet: http://www.raptmedia.com/product/ SCHOEFFMANN, Klaus; HUDELIST, Marco A. y HUBER, Jochen. Video Interaction Tools: A Survey of Recent Work [en línea]. En: ACM Computing Surveys. (Septiembre de 2015). [Consultado: 14 de octubre de 2017]. Disponible en Internet: https://www.researchgate.net/profile/Klaus_Schoeffmann2/publication/282468629_Video_Interaction_Tools/links/5744618f08aea45ee850cde5/Video-Interaction-Tools.pdf SOEGAARD, Mads. Gestalt principles of form perception [en línea]. Interaction-design.org. [Consultado: 14 de octubre de 2017]. Disponible en Internet: https://www.interaction-design.org/literature/book/the-glossary-of-human-computer-interaction/gestalt-principles-of-form-perception TRAVIS, David. ISO 13407 is dead. Long live ISO 9241-210! [en línea]. Userfocus.co.uk. (06 de junio de 2011). [Consultado: 14 de octubre de 2017]. Disponible en Internet: http://www.userfocus.co.uk/articles/iso-13407-is-dead.html U.S. Department of Health & Human Services. User-Centered Design Basics [en línea]. Usability.gov. [Consultado: 15 de octubre de 2017]. Disponible en Internet: https://www.usability.gov/what-and-why/user-centered-design.html Universidad Autónoma de Occidente. Video y Televisión Digital [en línea]. Uao.edu.co. [Consultado: 15 de octubre de 2017]. Disponible en Internet: http://ingenieria.uao.edu.co/multimedia/videoTV.html Universidad Militar Nueva Granada. Ingeniería en Multimedia [en línea]. Umng.edu.co. [Consultado: 14 de octubre de 2017]. Disponible en Internet: http://www.umng.edu.co/web/guest/programas-academicos/facultad-ingenieria/pregrados/ingenieria-multimedia Videopath. Our Product [en línea]. Videopath.com. (2016). [Consultado: 13 de octubre de 2017]. Disponible en Internet: https://videopath.com/product/

119

WAHNER, Kai. Pros and Cons – When to use a Portal and Portlets instead of just Java Web-Frameworks [en línea]. DZone / Java Zone. (13 de octubre de 2011). [Consultado: 13 de octubre de 2017]. Disponible en Internet: https://dzone.com/articles/pros-and-cons-%E2%80%93-when-use WAHNER, Kai. Pros and Cons – When to use a Portal and Portlets instead of just Java Web-Frameworks [en línea]. Dzone.com. (13 de octubre de 2011). [Consultado: 13 de octubre de 2017]. Disponible en Internet: https://dzone.com/articles/pros-and-cons-%E2%80%93-when-use Wirewax. Interactive video [en línea]. Wirewax.com. (2017) [Consultado: 13 de octubre de 2017]. Disponible en Internet: https://www.wirewax.com/what-is-this/ --------. Choose The Wirewax Offering That Works For You: You can even trial our Professional package free for 14 days. [en linea]. Wirewax.com. (2017). [Consultado: 13 de octubre de 2017]. Disponible en Internet: https://www.wirewax.com/pricing

120

ANEXOS Anexo A. Historias de usuario

ID #: 2 Título: Controlar el playback del video

Descripción: COMO estudiante de V&TVD

QUIERO controlar la reproducción del video

PARA ajustar su playback a mi voluntad

Criterios de validación:

El video ahora se visualiza con las nuevas características temporales y mediáticas.

RF’s asociados

RNF’s asociados

RF_01 RNF_01

Prioridad: Alta RF_05 RNF_02

RNF_03

RNF_04

ID #: 3 Título: Crear una cuenta

Descripción: COMO estudiante de V&TVD

QUIERO crear una cuenta personal en la plataforma

PARA compartir mi propio contenido

Criterios de validación:

Se agrega un nuevo registro a la tabla de usuarios en la base de datos de la plataforma.

RF’s asociados

RNF’s asociados

RF_12 RNF_13

121

Prioridad: Alta RF_13

RF_14

ID #: 4 Título: Ver un video

Descripción: COMO estudiante de V&TVD

QUIERO visualizar un video

PARA consumir la experiencia interactiva

Criterios de validación:

El video se reproduce con todas sus interacciones virtuales y físicas.

RF’s asociados

RNF’s asociados

RF_04 RNF_05

Prioridad: Alta RF_06 RNF_06

RF_07 RNF_07

RF_08 RNF_10

RF_09 RNF_11

RF_10 RNF_12

RF_11 RNF_13

RF_19 RNF_19

RNF_20

RNF_21

RNF_22

122

RNF_23

RNF_24

RNF_25

RNF_26

RNF_27

RNF_28

RNF_29

RNF_30

ID #: 5 Título: Socializar en la plataforma

Descripción: COMO estudiante de V&TVD

QUIERO dar mi opinión sobre el video

PARA compartir mi feedback con el resto de usuarios

Criterios de validación:

Se agrega a la base de datos la información de puntuación, comentarios y valoración del video.

RF’s asociados

RNF’s asociados

RF_15 RNF_12

Prioridad: Alta RF_16

RF_17

123

ID #: 6 Título: Buscar videos

Descripción: COMO estudiante de V&TVD

QUIERO buscar videos

PARA encontrar nuevo contenido de mi interés bajo mis términos de búsqueda

Criterios de validación:

Se muestran los videos cuyo nombre coincida con los términos de búsqueda.

RF’s asociados

RNF’s asociados

RF_18 RNF_01

Prioridad: Media RNF_02

RNF_13

RNF_14

ID #: 7 Título: Integrar laptop en módulo sensorial

Descripción: COMO estudiante de V&TVD

QUIERO usar mi laptop personal

PARA consumir el contenido de algún video

Criterios de validación:

La laptop se integra al objeto físico del módulo sensorial de tal forma que ninguna interacción ni el objeto físico se vean afectados.

RF’s asociados

RNF’s asociados

RF_19 RNF_15

Prioridad: Alta RNF_17

RNF_18

124

Anexo B. Esquema empleado para el SUS

Concepto

Totalmente Totalmente en desacuerdo de acuerdo

1 2 3 4 5

1 Creo que me gustaría usar el sistema

2 Considero que el sistema es innecesariamente complejo

3 Me pareció que el sistema era fácil de usar

4 Creo que necesitaría la ayuda de una persona técnica para poder usar el sistema

5 Considero que las distintas funciones en el sistema estaban bien integradas

6 Me pareció que había mucha inconsistencia en el sistema

7 Imagino que la mayoría de personas aprenderían a usar el sistema rápidamente

8 Considero que el sistema fue muy complicado de usar

9 Me sentí con confianza al usar el sistema

10 Tuve que aprender muchas cosas antes de poder empezar a usar el sistema

125

Anexo C. Resultados de la encuesta de caracterización de usuarios y contexto

126

Anexo D. Otros resultados de encuestas

Los resultados relevantes para otras áreas de la investigación se pueden encontrar en los siguientes enlaces: https://goo.gl/bhBr4b y https://goo.gl/5waume

127

Anexo E. Formato de encuesta de caracterización de usuarios y contexto ¿Cuál es su estrato socioeconómico?

1 2 3 4 5 6

¿Cuál es su estado civil?

Soltero Casado Viudo Divorciado Unión libre Otro: ___

Sexo

Masculino Femenino

¿Cuál es su edad?: ________ ¿Qué semestre cursa actualmente?

1 2 3 4 5 6 7 8 9 10 10+

¿En cual de los siguientes ambitos tiene mas afinidad a desempenarse profesionalmente?

Desarrollo de software Desarrollo de software y hardware

Desarrollo web Desarrollo para plataformas web

Diseño y desarrollo de videojuegos Diseño de experiencia de usuario

Diseño de interfaz de usuario Producción audiovisual

Modelado y animación 3D Docencia

Gerencia de proyectos Consultoría

Otro: ______

¿Bajo qué modalidad preferiría laborar?

Creación de startup / empresa

Empleado Independiente / Freelancer

Otro: _____

128

propia

¿Permanece en el Infolab o LCG para actividades diferentes a la asignatura?

Sí No A veces

Si la respuesta anterior fue “Si” o “A veces”. ¿Para qué?

Actividades especializadas

de otras asignaturas

Uso general de los

equipos de cómputo

Falta de espacio para

ubicarse

Lugar de encuentro

general

Otro: ______

¿Le interesa la temática alrededor de videos interactivos?

Sí No Más o menos

¿Para dar solución a los proyectos de la asignatura, ¿Usted preferiría desarrollar "desde cero" o hacer uso de una herramienta de soporte en caso de existir?

Desarrollar “desde cero” Usar herramientas de soporte

¿Con qué frecuencia requiere necesariamente de alguna herramienta especializada (software, hardware, etc.) para desarrollar sus proyectos?

Siempre A veces Nunca

Dentro de las opciones que encuentra, ¿La mayoría tienen una versión gratuita?

Sí No Algunas

Si no es así, ¿Estaría dispuesto a pagar?

Sí No Tal vez, dependiendo del precio

129

Si la respuesta anterior fue “Si” o “Tal vez”, ¿Cuanto estaria dispuesto a pagar?

< $10 USD < $20 USD < $50 USD > $50 USD

Dentro de las que tienen versión gratuita, ¿Con qué frecuencia se limitan las características disponibles versus una versión de pago?

Siempre A veces Nunca

¿Las características que normalmente usted usa/necesita están limitadas o bloqueadas?

Sí No A veces

Si no tuvieran una versión gratuita o están limitadas al punto de no poder ser usadas para la asignatura, ¿Preferiría desarrollarla usted mismo?

Sí No Tal vez, dependiendo de la dificultad

¿Considera que la calidad de su trabajo podría mejorar con la ayuda de una herramienta extra?

Sí No Tal vez

En este sentido, ¿Prefiere la tecnología Open Source?

Sí No

¿Ya vio o está viendo la asignatura de Computación Física?

Sí No

¿Ya vio o está viendo la asignatura de Interacción Hombre-Máquina?

Sí No

130

¿Ha desarrollado en Arduino antes?

Sí No Más o menos

¿Ha desarrollado con Raspberry Pi antes?

Sí No Más o menos

¿Utiliza alguna herramienta extra (framework, librería, sistema, software, aplicación web, etc.) para desarrollar los proyectos alrededor de videos interactivos?

Sí No Algunas veces

Si es así, ¿Cuáles?: _______ ¿Cuál considera que es su nivel en programación?

Alto Medio Bajo

¿Cuáles de los siguientes elementos considera que, como mínimo, debería poder incluir un video interactivo?

Áreas clickeables Imágenes Texto

Videos índice de contenidos Contenido web

Otro: ______

¿Cuáles de las siguientes acciones considera que, como mínimo, se deberían poder ejecutar en un video interactivo?

Pausar el video Reproducir el video Cambiar el tiempo (saltar a otra sección)

Cambiar el video en sí mismo

Otro: ______

131

¿Considera interesante la integración de elementos físicos/sensoriales en un video interactivo?

Sí No Más o menos

¿Cree que es posible crear experiencias más creativas e inmersivas a través de la integración de interacciones sensoriales en videos interactivos?

Sí No Tal vez

¿Le interesaría integrar tal sistema a sus proyectos de la asignatura?

Sí No Tal vez

¿Qué tipo de efectos consideraría adecuados?

Agua Luces Humo

Movimientos Olor Variación de temperatura

Viento Otro: ______

¿Qué tipo de controles esperaría de un reproductor para videos?

Barra de tiempo Control de volumen Control de playback (pausa/play, adelantar,

atrasar, etc)

Control de velocidad de reproducción

Ajustes visuales (brillo, contraste, etc.)

Activar/desactivar fullscreen

Otro: ______

Además de una herramienta para visualizar videos interactivos sin limitaciones, ¿Estaría interesado en una plataforma para cargarlos y compartirlos?

Sí No Tal vez

132

Anexo F. MER de la base de datos

133

Anexo G. Guion de entrevista post-test

1. ¿Presentó alguna dificultad con la interfaz del player? 2. ¿Presentó alguna dificultad con la interfaz de la plataforma? 3. ¿En qué actividades presentó mayor dificultad? 4. Si es así ¿Cómo las resolvería? 5. ¿Alguna sugerencia de mejora o comentario adicional?