Hoy, el aprendizaje en línea está comenzando a desplazar verdaderamente el aprendizaje a tiempo completo. Incluso algunas universidades rusas progresivas están introduciendo lentamente cursos en línea diseñados para reemplazar a las parejas dentro de los muros de las instituciones educativas. ¿Pero cuán real es todo esto? Hoy hablaremos sobre los problemas y las tendencias del aprendizaje en línea moderno.
¿Y qué es más conveniente para usted: ir a clases o estudiar en casa, envuelto en una tela escocesa?
Doy la palabra al autor.En este artículo, nos gustaría compartir con ustedes ideas sobre los problemas y las tendencias del aprendizaje en línea moderno, así como sobre la posibilidad de crear proyectos de realidad virtual que puedan integrarse con el aprendizaje electrónico moderno.
En el mundo moderno, el concepto de aprendizaje en línea (e-Learning) es complejo e incluye varios componentes:- Aprendizaje combinado : capacitación que combina clases con un instructor y capacitación en línea con opciones para actividades "no en clase". Un estudiante puede crear proyectos, usar la ayuda de mentores, etc. El aprendizaje combinado puede ser síncrono y asíncrono (la versión sincrónica implica una retroalimentación instantánea del desempeño académico del maestro. Asíncrono usa el concepto de tareas independientes en el hogar);
- Aprendizaje móvil : capacitación mediante dispositivos móviles;
- Aprendizaje informal : actividad fuera del entorno formal (clase, clase en línea, etc.). Este tipo de aprendizaje funciona a través de la interacción social.
Si consideramos la evolución del aprendizaje en línea en el contexto de las teorías socioculturales, entonces el desarrollo ocurrió del conductismo al constructivismo social. Inicialmente, el sistema de capacitación se basaba en principios conductistas: el maestro estaba ubicado en el centro y a su alrededor había estudiantes que lo escuchaban en silencio.
La transición a modelos de aprendizaje más complejos comenzó con el trabajo de Lev Vygotsky, quien sugirió que el aprendizaje ocurre como resultado de la interacción social con otras personas. De esta tesis han surgido teorías constructivistas. Sugieren que el conocimiento no es externo al alumno, es decir, cada alumno construye su propio modelo de un conocimiento específico. Usando estos modelos, el enfoque cambia de maestro a alumno, quien extrae conocimiento de una variedad de fuentes.
Algunos conceptos de aprendizaje más son modelos conectivistas y sociales. Sugieren que el conocimiento es una red de varias fuentes interconectadas. En consecuencia, la cantidad de conocimiento aumenta a medida que se agregan fuentes a la red. Las fuentes pueden ser, por ejemplo, personas o libros, o Internet.
Realizando conceptos
Surge la pregunta: "¿Cómo implementar todas las formas de capacitación?" Tradicionalmente, si consideramos el desarrollo de la esfera del e-Learning, se crearon enormes sistemas y protocolos bajo el concepto conductista (basado en la instrucción). Pero el punto era que todos los sistemas fueron construidos bajo la presencia de un cierto paquete de conocimiento. Se puede formar en la forma en que sea necesario para la integración en un sistema particular.
Construyendo un sistema de aprendizaje centrado en el estudiante y un nuevo protocolo de aprendizaje
Históricamente, el protocolo SCORM se usó inicialmente activamente en la Fuerza Aérea de los EE. UU. Y asumió un sistema de entrenamiento conductual. Y esto implicaba que las acciones del estudiante eran completamente irrelevantes: simplemente debía memorizar toda la información provista. SCORM, sin embargo, se está volviendo obsoleto y cada vez menos efectivo. Ahora surge la pregunta más urgente: "¿Cómo organizar un sistema educativo centrado en el estudiante utilizando servicios en línea en el mundo moderno?"
Para responder a esta pregunta, se deben tener en cuenta tres puntos:
- El sistema debe estar centrado en el alumno;
- El sistema debe apoyar el aprendizaje combinado;
- La capacitación en el sistema debe ser con experiencia social.
Para tener en cuenta la primera tesis, debe utilizar rutas de aprendizaje individuales. Sin embargo, con este enfoque, se hace necesario obtener una gran cantidad de datos sobre el comportamiento de los estudiantes.
Para resolver el problema estipulado en la segunda tesis, llegamos a la idea de las características de los protocolos actuales SCORM y AICC. Sugieren trabajar en línea, es decir, si la capacitación se lleva a cabo en un aula o aula, automáticamente su uso se vuelve imposible.
El problema principal en el campo de la educación social, como dice la tercera tesis, es la falta de desarrollo. Sin embargo, ahora se habla mucho sobre este tipo de entrenamiento, pero nadie sabe realmente cómo implementarlo correctamente. Ha llegado el momento de introducir nuevos estándares para los protocolos de capacitación. SCORM se reemplaza por xAPI.
xAPI
La idea principal detrás del desarrollo de xAPI es la separación de las estadísticas del contenido del material de capacitación en sí. Esto es necesario para opciones más flexibles para recopilar estas estadísticas. Por ejemplo, si el material de enseñanza no existe en formato electrónico, supongamos que el alumno recibe información a través de un libro.
Otro paradigma es la simulación, siempre se ha mantenido aparte. La simulación es un entorno en el que el alumno puede hacer lo que quiera. Sin embargo, para lograr el resultado deseado, la persona recibe datos de entrada, pero elige la "ruta" para pasar la simulación por sí misma. Actualmente, todos los juegos serios y de entrenamiento de realidad virtual funcionan fuera de los sistemas de entrenamiento con casi ningún intercambio de datos. xAPI le permite integrar el intercambio de datos en el entrenamiento de realidad virtual, lo que no es posible utilizando el protocolo SCORM.
Construyendo espacios virtuales
Tradicionalmente, los sistemas de e-learning han evolucionado como sistemas web. En consecuencia, el vector de desarrollo pasó de la Web 1.0 a la Web 2.0, es decir, a la creación de contenido generado por el usuario. Y este paradigma es muy adecuado para los sistemas de capacitación, principalmente debido al hecho de que les dio a los maestros medios bastante simples para crear contenido educativo.
Si observa cualquier sistema de gestión de aprendizaje ahora, proporciona medios bastante buenos para crear presentaciones, varias pruebas y todo lo necesario para desarrollar un curso de capacitación, mientras que todo esto se hace directamente en el navegador. Por supuesto, hay bastantes herramientas de autoría de terceros, y se usan activamente, especialmente para crear contenido más complejo, pero al final de la cadena todavía tenemos Internet y publicación en un formato adecuado para incrustar en una página web.
Pero el desarrollo de varios sistemas para trabajar con contenido 3D salió completamente mal. En primer lugar, no todos los juegos (y los juegos fueron lo suficientemente largos y siguen siendo uno de los motores de progreso en esta área) necesitaban una red. Y especialmente, la red es compleja. Además, los medios para crear contenido personalizado no son solo algo nuevo (los editores de nivel ya tienen muchos años), sino que también son medios para crear una funcionalidad fundamentalmente nueva, el modding profundo es notablemente más joven. Tradicionalmente se cree que un modder sabe lo que está haciendo, es decir, al menos un poco, pero sabe de programación, tiene una idea de una tubería para trabajar con modelos 3D y otras cosas específicas.
Pero en este caso, esto no es muy adecuado, ya que se requiere crear un sistema de capacitación y hacerlo accesible para todos. Es decir, es necesario simplificar y al mismo tiempo complicar el "modding", haciéndolo más similar al modelo Web 2.0., Sin perder la capacidad de uso múltiple. Intentemos ver cómo se ve un juego MMO estándar y pensar en lo que falta en dicha arquitectura.
Diferentes generaciones de MMO y enfoques de arquitectura
Si observamos (desde una altura muy alta, sin detalles) cómo se organiza cualquier espacio 3D multiusuario, por ejemplo, el MMO estándar de la era WoW, veremos algo como lo siguiente:
Naturalmente, hay un cliente y un servidor. La tarea principal del servidor es sincronizar las acciones de varios usuarios. Para esto, se determina un cierto protocolo fijo de comunicación entre el cliente y el servidor, con la ayuda de los cuales podemos enviar mensajes del cliente al servidor y, en el caso más simple, enviarlo a todos los demás clientes. (Por supuesto, hay una gran capa de matices asociados con la implementación de este proceso, por ejemplo, es el servidor autoritario, cómo se compensa el retraso, cómo funciona el trabajo con la física, etc., pero en este nivel del circuito vale la pena omitir esto). Además, necesita rastrear de alguna manera la lógica de las interacciones en el lado del servidor, por ejemplo, los scripts del juego. Para esto, lo más probable es que necesite algún tipo de script en el lado del servidor. Para simplificar la vida, las secuencias de comandos en el lado del cliente también son muy útiles.
Sin embargo, surge la pregunta: "¿Y de dónde viene el contenido real de este esquema, es decir, modelos, texturas, sonidos y todo eso?" Todo esto está dentro del cliente. Es por eso que los clientes MMO a menudo son tan pesados en términos de tamaño. Cuando se agrega algo nuevo, los usuarios deben descargar la actualización, y solo el desarrollador mismo, sus programadores y artistas pueden agregar algo nuevo.
Surge la pregunta: "¿Qué se debe cambiar en la arquitectura para permitir a los usuarios crear contenido?"
La idea parece almacenar inmediatamente contenido en el lado del servidor. En esta versión, el cliente es más como un navegador web: descarga todo lo que necesita y almacena en caché.
Se han realizado varios proyectos en esta dirección, el más famoso de los cuales, tal vez, es Second Life. El uso de tal esquema en su forma pura no siempre está justificado: a veces un enfoque híbrido es mejor cuando parte del contenido se descarga directamente (por ejemplo, al cargar una nueva escena) y la parte se carga dinámicamente.
La siguiente pregunta es qué hacer con la lógica. De todos modos, Second Life ofreció un esquema de secuencia de comandos del servidor, que era bastante único en ese momento: el usuario escribió el código del comportamiento del objeto en el editor de cliente incorporado, y luego la secuencia de comandos se envió al servidor y se ejecutó en él. Pero aquí, también, hay una serie de preguntas. Primero, el script debe tener acceso a algunos subsistemas clave del servidor, y surge la pregunta: ¿cuántos subsistemas deberían ser y cuáles deberían ser? En segundo lugar, hay una pregunta sobre cómo debería ser el lenguaje y cómo debería ser su biblioteca estándar: LSL, el lenguaje de scripting de Second Life, era bastante primitivo y complicado al mismo tiempo (por ejemplo, no había un trabajo normal con las matrices y no había OOP en principio).
Lejano Oriente
El concepto es algo similar a SL, pero difiere en varios detalles. Un elemento de un entorno virtual puede ser una aplicación completa que compila y tiene toda la lógica necesaria de trabajo "dentro", es decir, una especie de caja negra en términos de todo el sistema cliente-servidor y otras aplicaciones. Al mismo tiempo, todo el entorno virtual puede actuar como una posible, pero no la única, interfaz de aplicación. Complementa la biblioteca estándar, proporcionando una serie de funciones para trabajar con usted mismo. En otras palabras, este es un análogo de una aplicación ordinaria en un sistema operativo moderno, solo el entorno mismo realiza la función del sistema operativo.
Además de las interacciones en el espacio 3D, la aplicación virtual tiene acceso a la interfaz del cliente y la capacidad de crear sus propias partes de la interfaz. El resto, idealmente, la aplicación no debería saber nada sobre la división en cliente y servidor. El código debe escribirse de la misma manera que se escribiría una aplicación normal para un solo usuario.
Un entorno virtual, cuyos objetos son tales aplicaciones, lo llamamos un entorno virtual dinámico.
Sin embargo, surgen una serie de preguntas bastante obvias sobre la implementación práctica de dicho sistema: ¿cómo combinar tales principios con confiabilidad, rendimiento y muchos otros criterios, y cómo implementar la arquitectura específica de dicho proyecto? Hablaremos de esto en el próximo artículo.
Los autores
Jedium es una empresa asociada de Microsoft que trabaja en el campo de la realidad virtual aumentada y la inteligencia artificial. Jedium ha desarrollado un marco para simplificar el desarrollo de proyectos complejos en Unity, parte del cual está disponible públicamente
en GitHub . Jedium planea reponer el repositorio con nuevos módulos de marco, así como soluciones de integración con Microsoft Azure.
Vitaliy Chashchin : desarrollador de software con más de 10 años de experiencia en el diseño e implementación de aplicaciones tridimensionales cliente-servidor, desde el concepto hasta la implementación e integración completas de aplicaciones y soluciones en el campo de la realidad virtual. Arquitecto de sistemas Jedium LLC, MSc en TI.
Alexey SarafanovGerente de Marketing en Jedium LLC.
Sergey KudryavtsevCEO y fundador de Jedium LLC.