Сегодня онлайн-обучение начинает по-настоящему вытеснять очную форму получения знаний. Даже некоторые прогрессивные российские ВУЗы потихоньку внедряют онлайн-курсы, призванные заменить пары в стенах учебных заведений. Но насколько всё это реально? Сегодня поговорим о проблемах и тенденциях современного онлайн-обучения.
А что удобнее для вас: ездить на занятия или учиться дома, завернувшись в плед?
Передаю слово автору.
В этой статье мы хотели бы поделиться с вами мыслями о проблемах и трендах современного онлайн-обучения, а также о возможности создания VR — проектов, которые могут быть интегрированы с современным e-learning.
В современном мире понятие Онлайн-обучение (e-Learning), является комплексным и включает в себя несколько составляющих:
Если рассматривать эволюцию онлайн-обучения в контексте социокультурных теорий, то развитие происходило от бихевиоризма к социальному конструктивизму. Изначально система обучения строилась по бихевиористским принципам – в центре располагался учитель, а вокруг него ученики, которые молча его слушают.
Переход к более сложным моделям обучения начался с работ Льва Выготского, который предположил, что учеба происходит в результате социального взаимодействия с другими людьми. Из этого тезиса возникли конструктивистские теории. Они предполагают, что знания не являются внешними по отношению к ученику, а именно каждый ученик строит свою собственную модель какого-то конкретного знания. При использовании этих моделей фокус смещается с учителя на ученика, который черпает знания из самых разных источников.
Еще несколькими концепциями обучения являются коннективистская и социальная модели. Они предполагают, что знания — это сеть различных взаимосвязанных источников. Соответственно объем знаний увеличивается по мере добавления источников в сеть. Источниками могут быть как, например, люди или книги, так и интернет.
Возникает вопрос: “Как реализовать все формы обучения?” Традиционно, если рассматривать развитие сферы e-Learning, то огромные системы и протоколы создавались под бихевиористскую концепцию (instruction based). Но суть была в том, что все системы строились под наличие некоего пакета знаний. Его можно сформировать в той форме, в которой необходимо для интеграции в определенную систему.
Исторически сложилось, что протокол SCORM изначально активно использовался в ВВС США и предполагал именно бихевиористскую систему обучения. А это подразумевало, что действия студента совершенно не важны – он должен просто заучить всю предоставляемую информацию. Однако SCORM устаревает, и со временем становится все менее эффективным. Сейчас актуальнее встает вопрос: “Как правильно в современном мире организовать студентоцентрическую систему обучения именно с использованием онлайн-сервисов?”
Чтобы ответить на этот вопрос, необходимо учесть три тезиса:
Чтобы учесть первый тезис, нужно использовать индивидуальные траектории обучения. Однако при этом подходе становится необходимым получение огромного количества данных о поведении ученика.
Для решения задачи, оговоренной во втором тезисе, приходим к мысли об особенностях текущих протоколов SCORM и AICC. Они предполагают работу в онлайне, то есть если обучение происходит в классе или аудитории, то автоматически их использование становится невозможным.
Главная проблема в сфере социального обучения, о чем говорит третий тезис, это отсутствие развития. Однако сейчас про этот вид обучения много говорят, но никто толком не знает как правильно его реализовывать. Пришло время вводить новые стандарты протоколов обучения. На смену SCORM пришел xAPI.
Основная идея, которая стояла за разработкой xAPI – это отделение статистики от содержания самого материала обучения. Это нужно для более гибких вариантов сбора этой самой статистики. Например, если материал обучения не существует в электронной форме, допустим ученик получает информацию с помощью книги.
Еще одна из парадигм – это симуляция, она всегда стояла особняком. Симуляция – среда, в которой ученик может делать все что хочет. Однако, чтобы достичь желаемый результат, человеку даются вводные данные, но “маршрут” прохождения симуляции он выбирает сам. В настоящее время все VR-тренинги и серьезные игры работают вне учебных систем почти без обмена данными. xAPI позволяет интегрировать обмен данными в VR-тренинги, что невозможно при использовании протокола SCORM.
Традиционно системы e-learning развивались как веб-системы. Соответственно, вектор развития шел от Web 1.0 к Web 2.0 — то есть, к созданию пользовательского контента. И эта парадигма очень подошла системам обучения, прежде всего в силу того, что дала преподавателям достаточно простые средства для создания учебного контента.
Если посмотреть на любую Систему управления обучением сейчас, то она представляет достаточно неплохие средства для создания презентаций, различных тестов и всего необходимого для разработки учебного курса, при этом все это делается непосредственно в браузере. Конечно, есть довольно много сторонних authoring tools, и они активно используются, особенно для создания какого-либо более сложного контента — но в конце цепочки мы все равно имеем интернет и публикацию в формате, подходящем для встраивания в веб-страницу.
А вот развитие различных систем работы с 3D-контентом шло совсем не так. Прежде всего, далеко не всем играм (а игры достаточно долго были, и остаются сейчас, одним из двигателей прогресса в этой области) требовалась сеть. А особенно – сеть сложная. Более того, средства для создания пользовательского контента – штука не то чтобы новая (редакторам уровней уже очень много лет), но вот средства для создания принципиально нового функционала, глубокого моддинга – уже заметно моложе. Традиционно считается, что моддер знает, что делает, то есть он хотя бы немного, но разбирается в программировании, имеет представление о пайплайне для работы с 3D-моделями и прочими специфическими вещами.
Но в этом случае такое не очень подходит, так как требуется создать систему обучения, и сделать ее доступной всем. То есть, нужно упростить и одновременно усложнить “моддинг”, сделав его более похожим на модель Web 2.0., при этом не потеряв многопользовательность. Попробуем сначала посмотреть на то, как обычно выглядит стандартная MMO-игра, и подумать, чего не хватает в такой архитектуре.
Если посмотреть (с очень большой высоты, без деталей) на то, как устроено какое-либо многопользовательское 3D-пространство, например, стандартная MMO времен WoW, то мы увидим примерно следующее:
Естественно, есть клиент и сервер. Основная задача сервера — синхронизация действий различных пользователей. Для этого определяется некий фиксированный протокол общения между клиентом и сервером, с помощью которого мы можем пересылать сообщения от клиента на сервер и, в простейшем случае, рассылать всем остальным клиентам. (Конечно, тут есть огромный пласт нюансов, связанных с реализацией этого процесса – например, является ли сервер авторитарным, как компенсируется лаг, как идет работа с физикой и т.д. – но на данном уровне схемы стоит это пропустить). Кроме того, нужно как-то отслеживать логику взаимодействий на стороне сервера, например, игровые сценарии. Для этого, скорее всего, понадобится какой-то скриптинг на стороне сервера. Для упрощения жизни также очень пригодится скриптинг и на стороне клиента.
Возникает, однако, вопрос: “А откуда в этой схеме берется собственно контент, то есть модели, текстуры, звуки и все прочее?”. Все это находится “внутри” клиента. Именно поэтому клиенты MMO часто такие тяжелые в плане размера. Когда добавляется что-то новое, пользователи должны скачивать обновление, а добавить что-то новое может только сам разработчик, его программисты и художники.
Возникает вопрос: “Что нужно изменить в архитектуре, чтобы дать пользователям возможность создавать контент?”
Сразу же появляется идея хранить контент на стороне сервера. В этом варианте клиент больше похож на веб-браузер – он скачивает все необходимое и кэширует.
В этом направлении было сделано несколько проектов, самым известным из которых, пожалуй, является Second Life. Использование подобной схемы в чистом виде не всегда оправдано – иногда лучше гибридный подход, когда часть контента скачивается в прямом виде (например, при загрузке новой сцены), а часть – загружается динамически.
Следующий вопрос – что делать с логикой. Все тот же Second Life предложил достаточно уникальную на тот момент схему серверного скриптинга – пользователь писал код поведения объекта во встроенном клиент-редакторе, а дальше скрипт отсылался на сервер и выполнялся на нем же. Но здесь тоже есть ряд вопросов. Во-первых, скрипт должен иметь доступ к каким-то ключевым подсистемам сервера, и возникает вопрос – сколько должно быть таких подсистем и какими они должны быть? Во-вторых, есть вопрос о том, какой это должен быть язык и как должна выглядеть его стандартная библиотека – LSL, язык скриптинга Second Life, был довольно примитивен и усложнен одновременно (например, там не было нормальной работы с массивами и не было ООП в принципе).
Концепция чем-то похожа на SL, но отличается рядом деталей. Элементом виртуальной среды может быть полноценное приложение, которое компилируется и обладает всей необходимой логикой работы “внутри” себя, т.е. своего рода черный ящик с точки зрения всей системы “клиент-сервер” и других приложений. При этом в роли возможного, но не единственного, интерфейса приложения может выступать вся виртуальная среда. Она же дополняет стандартную библиотеку, предоставляя ряд функций для работы с собой. Другими словами, это аналог обыкновенного приложения в современной операционной системе, просто функцию ОС выполняет сама среда.
Кроме самих взаимодействий в 3D-пространстве, виртуальное приложение имеет доступ к интерфейсу клиента и возможность создавать свои части интерфейса. В остальном – в идеале – приложению ничего не должно быть известно о делении на клиент и сервер. Код должен писаться аналогично тому, как писалось бы обычное однопользовательское приложение.
Виртуальную среду, объекты которой представляют собой такие приложения, мы называем динамическим виртуальным окружением.
Возникает, однако, ряд вполне очевидных вопросов о практическом воплощении такой системы – как совместить подобные принципы с надежностью, производительностью и многими другими критериями, и как реализовать конкретную архитектуру подобного проекта? Об этом мы расскажем в следующей статье.
Компания Jedium — партнерская компания Microsoft, работающая в сфере виртуальной, дополненной реальности и искусственного интеллекта. Jedium разработала фреймворк для упрощения разработки комплексных проектов на Unity, часть которого находится в открытом доступе на GitHub. Jedium планирует пополнять репозиторий новыми модулями фреймворка, а также интеграционными решениями с Microsoft Azure.
Виталий Чащин — Разработчик программного обеспечения с более чем 10 годами опыта в дизайне и реализации трехмерных клиент-серверных приложений – от концепции до полной реализации и интеграции приложений и решений в области виртуальной реальности. Системный архитектор Jedium LLC, MSc in IT.
Алексей Сарафанов
менеджер по маркетингу в Jedium LLC.
Сергей Кудрявцев
CEO and founder of Jedium LLC.
А что удобнее для вас: ездить на занятия или учиться дома, завернувшись в плед?
Передаю слово автору.
В этой статье мы хотели бы поделиться с вами мыслями о проблемах и трендах современного онлайн-обучения, а также о возможности создания VR — проектов, которые могут быть интегрированы с современным e-learning.
В современном мире понятие Онлайн-обучение (e-Learning), является комплексным и включает в себя несколько составляющих:
- Blended learning – обучение, сочетающие в себе занятия с инструктором и обучение в сети с вариантами деятельности “не в классе”. Студент может создавать проекты, пользоваться помощью менторов и так далее. Blended learning бывает синхронным и асинхронным (Синхронный вариант подразумевает моментальный отзыв об успеваемости от преподавателя. Асинхронный использует концепцию домашних самостоятельных заданий);
- Mobile learning – Обучение с использованием мобильных девайсов;
- Неформальное обучение (informal learning) – деятельность вне формальной среды (класс, онлайн-класс и т.п.). Этот тип обучения работает с помощью социального взаимодействия.
Если рассматривать эволюцию онлайн-обучения в контексте социокультурных теорий, то развитие происходило от бихевиоризма к социальному конструктивизму. Изначально система обучения строилась по бихевиористским принципам – в центре располагался учитель, а вокруг него ученики, которые молча его слушают.
Переход к более сложным моделям обучения начался с работ Льва Выготского, который предположил, что учеба происходит в результате социального взаимодействия с другими людьми. Из этого тезиса возникли конструктивистские теории. Они предполагают, что знания не являются внешними по отношению к ученику, а именно каждый ученик строит свою собственную модель какого-то конкретного знания. При использовании этих моделей фокус смещается с учителя на ученика, который черпает знания из самых разных источников.
Еще несколькими концепциями обучения являются коннективистская и социальная модели. Они предполагают, что знания — это сеть различных взаимосвязанных источников. Соответственно объем знаний увеличивается по мере добавления источников в сеть. Источниками могут быть как, например, люди или книги, так и интернет.
Претворение концепций в жизнь
Возникает вопрос: “Как реализовать все формы обучения?” Традиционно, если рассматривать развитие сферы e-Learning, то огромные системы и протоколы создавались под бихевиористскую концепцию (instruction based). Но суть была в том, что все системы строились под наличие некоего пакета знаний. Его можно сформировать в той форме, в которой необходимо для интеграции в определенную систему.
Построение студентоцентрической системы обучения и новый протокол обучения
Исторически сложилось, что протокол SCORM изначально активно использовался в ВВС США и предполагал именно бихевиористскую систему обучения. А это подразумевало, что действия студента совершенно не важны – он должен просто заучить всю предоставляемую информацию. Однако SCORM устаревает, и со временем становится все менее эффективным. Сейчас актуальнее встает вопрос: “Как правильно в современном мире организовать студентоцентрическую систему обучения именно с использованием онлайн-сервисов?”
Чтобы ответить на этот вопрос, необходимо учесть три тезиса:
- Система должна быть студентоцентрической;
- Система должна поддерживать смешанное обучение;
- Обучение в системе должно быть с социальным опытом.
Чтобы учесть первый тезис, нужно использовать индивидуальные траектории обучения. Однако при этом подходе становится необходимым получение огромного количества данных о поведении ученика.
Для решения задачи, оговоренной во втором тезисе, приходим к мысли об особенностях текущих протоколов SCORM и AICC. Они предполагают работу в онлайне, то есть если обучение происходит в классе или аудитории, то автоматически их использование становится невозможным.
Главная проблема в сфере социального обучения, о чем говорит третий тезис, это отсутствие развития. Однако сейчас про этот вид обучения много говорят, но никто толком не знает как правильно его реализовывать. Пришло время вводить новые стандарты протоколов обучения. На смену SCORM пришел xAPI.
xAPI
Основная идея, которая стояла за разработкой xAPI – это отделение статистики от содержания самого материала обучения. Это нужно для более гибких вариантов сбора этой самой статистики. Например, если материал обучения не существует в электронной форме, допустим ученик получает информацию с помощью книги.
Еще одна из парадигм – это симуляция, она всегда стояла особняком. Симуляция – среда, в которой ученик может делать все что хочет. Однако, чтобы достичь желаемый результат, человеку даются вводные данные, но “маршрут” прохождения симуляции он выбирает сам. В настоящее время все VR-тренинги и серьезные игры работают вне учебных систем почти без обмена данными. xAPI позволяет интегрировать обмен данными в VR-тренинги, что невозможно при использовании протокола SCORM.
Построение виртуальных пространств
Традиционно системы e-learning развивались как веб-системы. Соответственно, вектор развития шел от Web 1.0 к Web 2.0 — то есть, к созданию пользовательского контента. И эта парадигма очень подошла системам обучения, прежде всего в силу того, что дала преподавателям достаточно простые средства для создания учебного контента.
Если посмотреть на любую Систему управления обучением сейчас, то она представляет достаточно неплохие средства для создания презентаций, различных тестов и всего необходимого для разработки учебного курса, при этом все это делается непосредственно в браузере. Конечно, есть довольно много сторонних authoring tools, и они активно используются, особенно для создания какого-либо более сложного контента — но в конце цепочки мы все равно имеем интернет и публикацию в формате, подходящем для встраивания в веб-страницу.
А вот развитие различных систем работы с 3D-контентом шло совсем не так. Прежде всего, далеко не всем играм (а игры достаточно долго были, и остаются сейчас, одним из двигателей прогресса в этой области) требовалась сеть. А особенно – сеть сложная. Более того, средства для создания пользовательского контента – штука не то чтобы новая (редакторам уровней уже очень много лет), но вот средства для создания принципиально нового функционала, глубокого моддинга – уже заметно моложе. Традиционно считается, что моддер знает, что делает, то есть он хотя бы немного, но разбирается в программировании, имеет представление о пайплайне для работы с 3D-моделями и прочими специфическими вещами.
Но в этом случае такое не очень подходит, так как требуется создать систему обучения, и сделать ее доступной всем. То есть, нужно упростить и одновременно усложнить “моддинг”, сделав его более похожим на модель Web 2.0., при этом не потеряв многопользовательность. Попробуем сначала посмотреть на то, как обычно выглядит стандартная MMO-игра, и подумать, чего не хватает в такой архитектуре.
Различные поколения MMO и подходы к архитектуре
Если посмотреть (с очень большой высоты, без деталей) на то, как устроено какое-либо многопользовательское 3D-пространство, например, стандартная MMO времен WoW, то мы увидим примерно следующее:
Естественно, есть клиент и сервер. Основная задача сервера — синхронизация действий различных пользователей. Для этого определяется некий фиксированный протокол общения между клиентом и сервером, с помощью которого мы можем пересылать сообщения от клиента на сервер и, в простейшем случае, рассылать всем остальным клиентам. (Конечно, тут есть огромный пласт нюансов, связанных с реализацией этого процесса – например, является ли сервер авторитарным, как компенсируется лаг, как идет работа с физикой и т.д. – но на данном уровне схемы стоит это пропустить). Кроме того, нужно как-то отслеживать логику взаимодействий на стороне сервера, например, игровые сценарии. Для этого, скорее всего, понадобится какой-то скриптинг на стороне сервера. Для упрощения жизни также очень пригодится скриптинг и на стороне клиента.
Возникает, однако, вопрос: “А откуда в этой схеме берется собственно контент, то есть модели, текстуры, звуки и все прочее?”. Все это находится “внутри” клиента. Именно поэтому клиенты MMO часто такие тяжелые в плане размера. Когда добавляется что-то новое, пользователи должны скачивать обновление, а добавить что-то новое может только сам разработчик, его программисты и художники.
Возникает вопрос: “Что нужно изменить в архитектуре, чтобы дать пользователям возможность создавать контент?”
Сразу же появляется идея хранить контент на стороне сервера. В этом варианте клиент больше похож на веб-браузер – он скачивает все необходимое и кэширует.
В этом направлении было сделано несколько проектов, самым известным из которых, пожалуй, является Second Life. Использование подобной схемы в чистом виде не всегда оправдано – иногда лучше гибридный подход, когда часть контента скачивается в прямом виде (например, при загрузке новой сцены), а часть – загружается динамически.
Следующий вопрос – что делать с логикой. Все тот же Second Life предложил достаточно уникальную на тот момент схему серверного скриптинга – пользователь писал код поведения объекта во встроенном клиент-редакторе, а дальше скрипт отсылался на сервер и выполнялся на нем же. Но здесь тоже есть ряд вопросов. Во-первых, скрипт должен иметь доступ к каким-то ключевым подсистемам сервера, и возникает вопрос – сколько должно быть таких подсистем и какими они должны быть? Во-вторых, есть вопрос о том, какой это должен быть язык и как должна выглядеть его стандартная библиотека – LSL, язык скриптинга Second Life, был довольно примитивен и усложнен одновременно (например, там не было нормальной работы с массивами и не было ООП в принципе).
ДВО
Концепция чем-то похожа на SL, но отличается рядом деталей. Элементом виртуальной среды может быть полноценное приложение, которое компилируется и обладает всей необходимой логикой работы “внутри” себя, т.е. своего рода черный ящик с точки зрения всей системы “клиент-сервер” и других приложений. При этом в роли возможного, но не единственного, интерфейса приложения может выступать вся виртуальная среда. Она же дополняет стандартную библиотеку, предоставляя ряд функций для работы с собой. Другими словами, это аналог обыкновенного приложения в современной операционной системе, просто функцию ОС выполняет сама среда.
Кроме самих взаимодействий в 3D-пространстве, виртуальное приложение имеет доступ к интерфейсу клиента и возможность создавать свои части интерфейса. В остальном – в идеале – приложению ничего не должно быть известно о делении на клиент и сервер. Код должен писаться аналогично тому, как писалось бы обычное однопользовательское приложение.
Виртуальную среду, объекты которой представляют собой такие приложения, мы называем динамическим виртуальным окружением.
Возникает, однако, ряд вполне очевидных вопросов о практическом воплощении такой системы – как совместить подобные принципы с надежностью, производительностью и многими другими критериями, и как реализовать конкретную архитектуру подобного проекта? Об этом мы расскажем в следующей статье.
Авторы
Компания Jedium — партнерская компания Microsoft, работающая в сфере виртуальной, дополненной реальности и искусственного интеллекта. Jedium разработала фреймворк для упрощения разработки комплексных проектов на Unity, часть которого находится в открытом доступе на GitHub. Jedium планирует пополнять репозиторий новыми модулями фреймворка, а также интеграционными решениями с Microsoft Azure.
Виталий Чащин — Разработчик программного обеспечения с более чем 10 годами опыта в дизайне и реализации трехмерных клиент-серверных приложений – от концепции до полной реализации и интеграции приложений и решений в области виртуальной реальности. Системный архитектор Jedium LLC, MSc in IT.
Алексей Сарафанов менеджер по маркетингу в Jedium LLC.
Сергей Кудрявцев CEO and founder of Jedium LLC.
