Ветвящиеся сценарии: видео с выбором пути

Кратко

Ветвящийся сценарий – это видеоурок, который останавливается в точках выбора: учащийся решает, что делать дальше, и видит последствия своего выбора. Пассивный просмотр превращается в отработку решений. Технически сценарий – это граф из узлов (видеофрагментов) и рёбер (выборов между ними). Главный риск в том, что каждая новая ветка умножает объём съёмок, и стоимость растёт быстрее, чем польза для обучения. Настоящий продукт от кликабельного демо отличают две инженерные задачи. Первая – трекинг состояния: помнить, где учащийся и что он выбрал, чтобы он мог продолжить с того же места, а вы – засчитать концовку. Вторая – аналитика путей: видеть, какими маршрутами учащиеся идут на самом деле. Обе держатся на правильно составленных xAPI-утверждениях. В статье – модель «узел-ребро» простым языком, расчёт стоимости ветвления, трекинг и аналитика путей по спецификациям и тест, когда ветвление оправдано.

Почему это важно

Если вы L&D-директор, основатель EdTech-компании или продакт-менеджер, ветвящееся видео – тот формат, который заказчики просят, когда хотят, чтобы обучение было «как в жизни», и тот, что чаще всего выходит за бюджет. Он хорошо подходит для тренировки суждений: разговор с рассерженным клиентом, проверка по технике безопасности, клиническое решение. Но сценарий с тридцатью отснятыми концовками может стоить в десять раз дороже обычной лекции и учить не лучше продуманной версии с тремя ветками. Статья поможет трезво оценить ветвление: что именно вы покупаете, где прячутся расходы, как отслеживается путь учащегося и когда более простое интерактивное видео справится не хуже и намного дешевле. Самый простой интерактивный элемент разобран в статье Квизы и опросы в плеере, ветвление – самый дорогой.

Сначала – что такое ветвящийся сценарий

Начнём с бытовой аналогии. Вспомните книгу-игру: вы читаете страницу и доходите до выбора («чтобы открыть дверь, перейдите на страницу 42; чтобы уйти – на страницу 58»), и дальнейшая история зависит от того, что вы выбрали. Ветвящийся сценарий – та же идея, только из видео. Учащийся смотрит короткий клип с завязкой ситуации, видео останавливается и предлагает выбор, а следующий клип показывает последствия. Выбрал верно – ситуация улучшается; ошибся – видишь, как всё идёт не так, но безопасно, на экране, где ошибка ничего не стоит.

Зачем это нужно, понятно из того, как осваиваются навыки. Наблюдая, как кто-то ведёт трудный разговор, человек получает знание; принимая решение сам и видя последствия, он вырабатывает навык. В методологии это называют сценарным обучением. Оно ценнее всего там, где заучивание процедуры не помогает: суждения, мягкие навыки и ситуации, слишком опасные или деликатные, чтобы репетировать их вживую. Ветвящийся сценарий позволяет отработать решение, а не просто вспомнить регламент.

Хороший сценарий строится так же, как у сценаристов: завязка (ситуация из реальной жизни учащегося), конфликт (проблема, которая вынуждает выбирать) и развязка (что из этого вышло). Завязку делайте простой и явно вымышленной, каждый конфликт стройте вокруг одного учебного тезиса, а в развязке показывайте последствия, а не сообщайте учащемуся, прав он или нет. Именно такая обратная связь по принципу «показывай, а не рассказывай» заставляет формат учить, а не экзаменовать.

Модель «узел-ребро»: как устроен ветвящийся сценарий

Чтобы построить или купить сценарий, нужно понимать, что у него внутри. Любой ветвящийся сценарий – это граф, структура всего из двух элементов: узлов и рёбер.

Узел – единица контента, которую видит учащийся: видеофрагмент, вопрос или экран-концовка, то есть одна страница книги-игры. Ребро – переход от одного узла к другому по выбору учащегося: «если выбрана деэскалация, перейти к узлу 7». Путь учащегося по сценарию – просто маршрут по рёбрам от стартового узла до одной из концовок.

Это не академическая абстракция: именно так сценарий показывают инструменты авторинга и именно это записывает система трекинга. Самый распространённый способ собирать такие сценарии – тип контента Branching Scenario в бесплатном open-source-инструменте H5P. Он позволяет «структурировать контент как дерево с множеством веток и концовок», где любой выбор «может вести к любому другому узлу в структуре дерева интерактивности». Деталь важная: рёбра могут вести назад или вбок, а не только вперёд, и тогда простое дерево превращается в граф общего вида. Отсюда и гибкость, и сложность.

Нажмите, чтобы увеличить

Узлов бывает три типа. Контентный узел показывает видеофрагмент, после которого сценарий либо идёт дальше сам, либо предлагает выбор. Узел решения – развилка: пауза с вопросом «что вы сделаете?» и двумя-четырьмя вариантами, каждый из которых ведёт ребром к своему узлу. Узел-концовка завершает путь и обычно содержит балл или разбор. С этими понятиями проще и проектировать сценарий, и настраивать трекинг.

Главная проблема: стоимость ветвления растёт быстрее, чем кажется

На этом и проваливаются проекты с ветвлением. Каждая точка решения умножает объём съёмок, и множители накапливаются.

Посчитаем. Пусть в каждом решении 3 варианта и после каждого выбора учащийся попадает на следующее решение. Одно решение – это 3 клипа с последствиями. Если каждый из них ведёт к новому решению с 3 вариантами, на втором уровне уже 3 × 3 = 9 клипов, на третьем – 3 × 3 × 3 = 27. Общая формула:

клипов на глубине D  =  (вариантов на решение) ^ D

Значит, сценарий с 3 вариантами и глубиной в 4 решения, если снимать отдельный путь под каждую комбинацию, требует 3⁴ = 81 разную концовку, а вместе с промежуточными клипами – заметно больше сотни видеофрагментов. Это комбинаторный взрыв: число клипов растёт экспоненциально с глубиной, и даже «скромный» сценарий становится неподъёмным. Линейный урок той же длины – несколько клипов, ветвящийся в полном раскрытии – больше сотни.

Никто не снимает 81 концовку. Мастерство проектирования ветвления почти целиком сводится к тому, чтобы сдержать этот рост и не потерять учебный эффект. Для этого есть три приёма.

Первый – золотой путь (его ещё называют критическим): снимают только идеальный маршрут и самые поучительные ошибочные повороты. Ветки, куда учащиеся заглядывали бы редко, не снимают вовсе. Второй – слияние веток: после неверного выбора и его последствий путь возвращается в общий узел, а не порождает собственное поддерево. Слияние превращает экспоненциальный рост почти в линейный: один и тот же десяток клипов с последствиями используется во многих путях. Третий – ограничение глубины: не больше двух-трёх решений подряд. Практики и исследования сходятся в том, что четвёртая-пятая развилка подряд редко окупает свою экспоненциальную стоимость.

Нажмите, чтобы увеличить

На графике разница видна наглядно: полное дерево (оранжевая линия) – счёт, который никто не оплатит, а схема со слиянием (зелёная) – то, что на практике и снимают.

Нажмите, чтобы увеличить

Разработка: сначала граф, потом камера

Самая дорогая ошибка в ветвлении – начать съёмки до того, как согласован граф. Если сценарий перестроили после съёмок, придётся переснимать. Поэтому порядок работ жёсткий: сначала граф – на бумаге или в простом инструменте, – затем проверка с предметным экспертом, и только потом камера.

Стандартный инструмент для прототипа – Twine, бесплатный open-source-редактор нелинейных историй с экспортом в обычный HTML. В нём команда пишет и прокликивает всю структуру решений – каждый узел, ребро и концовку – только текстом. Инструмент бесплатный и быстрый, поэтому не жалко выбросить три версии, прежде чем остановиться на четвёртой. Кристи Такер и Кэти Мур, известные специалисты по сценарному обучению, обе советуют начинать с прототипа в Twine: так снижается риск на самом дорогом этапе – съёмках.

Когда граф проверен, выбирают рабочий инструмент. Варианты выглядят так:

Таблица 1. Инструменты для ветвящихся сценариев. Столбец «Поддержка стандартов» показывает, можно ли отслеживать сценарий через LMS или LRS: кликабельный сценарий, который ничего не отправляет, в отчётах не виден.

Картина понятная: бесплатных и недорогих инструментов (Twine, H5P) и российского iSpring Suite хватает для большинства задач, с них и стоит начинать. С зарубежными облачными конструкторами осторожнее: если сервис хранит выборы и результаты учащихся на своих серверах за рубежом, это противоречит требованию о локализации ПДн (ч. 5 ст. 18 152-ФЗ). К собственной разработке переходят, когда нужен более глубокий контроль, плотная интеграция с фирменным стилем и плеером или трекинг, которого не дают готовые инструменты. Здесь и проходит граница между покупкой и разработкой.

Трекинг состояния: помнить, где учащийся

У ветвящегося сценария есть свойство, которого нет у линейного видео: учащийся находится в конкретной точке графа и пришёл туда конкретным маршрутом. Сохранение этой информации называют трекингом состояния, и у него две задачи. Первая – возобновление: учащийся, закрывший вкладку на узле 9, должен вернуться на узел 9, а не начинать сначала. Если 20-минутный сценарий после перерыва приходится проходить заново, учащиеся его почти наверняка бросают. Вторая – оценка: до какой концовки дошёл учащийся и какие выборы к ней привели. Именно это попадает в отчёт.

Для этого служит стандарт Experience API (xAPI): с его помощью плеер записывает в базу короткие фразы о действиях учащегося. Каждая такая фраза – xAPI-утверждение вида субъект – глагол – объект: «Мария – выбрала – деэскалацию». Утверждения отправляются в Learning Record Store (LRS) – хранилище учебных записей (структуру утверждения и LRS определяет спецификация xAPI версии 1.0.3). При каждом выборе плеер отправляет утверждение, и последовательность этих утверждений и есть путь учащегося.

Для возобновления в xAPI есть отдельный механизм – State Resource (xAPI 1.0.3, часть 3). Плеер сохраняет в нём небольшой документ вроде «текущий узел: 9, путь: [1,4,7,9]», привязанный к учащемуся и активности, а при следующем входе считывает его и возвращает учащегося точно туда, где он остановился. Данные возобновления живут в State Resource, постоянная запись – в утверждениях, и задачи не смешиваются. И то и другое привязано к конкретному человеку, то есть это персональные данные: LRS и хранилище состояния российского продукта должны работать на базах данных в России.

Если сценарий запускается из системы управления обучением (LMS) через cmi5 – современный профиль, который позволяет запускать xAPI-контент из LMS так же, как SCORM, – пригодится ещё одно правило. В cmi5 есть свойство moveOn: оно сообщает LMS, что считать выполнением. Допустимые значения – Passed, Completed, CompletedAndPassed, CompletedOrPassed и NotApplicable (спецификация cmi5, раздел 13.1.4). В ветвящемся сценарии с его помощью можно сделать так, чтобы «учащийся дошёл до проходной концовки» означало «можно двигаться дальше». Это куда честнее, чем «досмотрел до последней секунды».

Нажмите, чтобы увеличить

Каждый клип в сценарии – обычное видео, поэтому можно отслеживать и то, что происходит внутри него, – played, paused, seeked, completed – через xAPI Video Profile (профиль сообщества ADL версии 1.0.3), где определены как раз эти глаголы. В ветвящемся сценарии такая детализация нужна редко: выбор важнее того, куда учащийся двигал ползунок. Но она доступна, если нужно измерять и вовлечённость внутри клипа. Подробнее – в статье Трекинг видео через xAPI.

Аналитика путей: какими маршрутами идут учащиеся

Когда выборы попадают в LRS в виде утверждений, можно ответить на вопрос, ради которого ветвление и затевают: что учащиеся решают на самом деле? Это аналитика путей, и именно ради неё формат стоит своих денег.

Почти всё дают три среза. Распределение выборов показывает для каждого узла решения, какая доля учащихся выбрала каждый вариант. Если в каком-то узле 80% выбирают неверный ответ, это либо удачный учебный момент, либо плохо сформулированный вопрос, и данные помогут понять, что именно. Частота путей показывает самые популярные маршруты от старта до концовки и выявляет, заходят ли учащиеся в ваши дорогие ветки вообще (часто нет, и в следующий раз их можно не снимать). Отвал показывает, где учащиеся бросают сценарий; обычно это признак запутанного решения или слишком длинного пути.

Но аналитика хороша ровно настолько, насколько хороши отправляемые утверждения. Если плеер сообщает только «сценарий завершён», а отдельные выборы не пишет, вы получите процент завершения – и всё: ни распределения выборов, ни частоты путей, ни данных, чтобы улучшить сценарий. Поэтому утверждение нужно отправлять на каждом решении, с выбранным вариантом в поле результата, чтобы путь восстанавливался полностью. Слой аналитики, который обрабатывает эти утверждения, разобран в статье Аналитика обучения; задача этой статьи – сделать так, чтобы данным для анализа было откуда взяться.

Частая ошибка: принимать клики за обучение

В проектах с ветвлением раз за разом повторяется одна ошибка: интерактивность принимают за доказательство того, что люди учатся. Сценарий, где любой выбор вызывает похвалу или «неверный» вариант очевиден по формулировке, даёт клики и завершения, но ничему не учит. И при этом стоит как полноценное ветвление.

Лечится это дисциплиной проектирования, а не технологиями. Делайте неверные варианты по-настоящему правдоподобными – такими, какие выбрал бы реальный добросовестный сотрудник. Пусть последствия ошибки будут ощутимыми и сами объясняют, что пошло не так, вместо мигающей надписи «неверно». И измеряйте то, что важно: не «дошёл ли учащийся до конца», а «сместилось ли распределение выборов к лучшему ответу при второй попытке или в следующем сценарии». Ветвящийся сценарий, который не меняет поведение, – просто дорогое видео с кнопками. Привяжите завершение к проходной концовке (через moveOn в cmi5), а не к тому, что ползунок дошёл до конца, – тогда учащемуся придётся хотя бы добраться до хорошего исхода.

Когда ветвление оправдано

Ветвление – самый дорогой интерактивный формат, поэтому до выбора между покупкой и разработкой стоит понять, нужно ли оно вообще. Сначала взвесьте затраты и пользу, потом беритесь за разработку.

Ветвление окупается, когда учебная цель – суждение, которое нужно отработать в реалистичных условиях (руководитель разбирает конфликт в команде, медсестра проводит сортировку пациентов, продавец работает с сомневающимся покупателем), и когда ошибка в реальной жизни стоит дорого или опасна. Тогда безопасная репетиция важного решения оправдывает серьёзные расходы на производство, а более простой формат действительно не справится.

Ветвление не оправдано, если цель – передать знания (регламент, процесс, характеристики продукта), если есть одна верная процедура, где не нужно ничего решать, или если бюджет ставит перед выбором: один отполированный ветвящийся сценарий или десять добротных линейных уроков, которые покрывают в десять раз больше программы. В этих случаях квиз в плеере или кликабельные хотспоты дают почти ту же вовлечённость за малую долю стоимости. Разумное правило по умолчанию: ветвите редко, неглубоко и по максимуму переиспользуйте клипы.

Нажмите, чтобы увеличить

Чтобы принять решение предметно, скачайте рабочий лист: на одной странице – граф, золотой путь, план слияния веток, чек-лист трекинга и тест «купить или разработать».

Скачать рабочий лист проектирования ветвящегося сценария (PDF)

Где здесь Фора Софт

Фора Софт делает интерактивные и стриминговые видеопродукты с 2005 года. Ветвящееся видео находится на стыке двух вещей, которыми мы занимаемся каждый день: собственных видеоплееров и слоя трекинга, который превращает просмотр в учебные данные. К нам приходят, когда готовый инструмент не даёт нужного контроля над плеером, фирменного интерфейса или глубины аналитики, – то есть когда вопрос уже не «какой инструмент купить», а «что разработать». Мы помогаем трезво это оценить: часто правильный ответ – H5P или iSpring Suite, и мы так и скажем. Когда собственный движок ветвления с полной xAPI-аналитикой путей действительно оправдан, мы его разрабатываем. Та же команда работает в e-learning, видеоконференциях, OTT, телемедицине и AR/VR, поэтому решения для плеера и трекинга проверены на практике.

Ключевые выводы

• Ветвящийся сценарий – граф из видеоузлов, соединённых рёбрами-выборами; путь учащегося – один маршрут по нему.
• Стоимость растёт экспоненциально с глубиной. Сдерживайте её золотым путём, слиянием веток и лимитом в 2–3 решения.
• Раскадруйте и прокликайте граф (в Twine) до съёмок: видео дёшево не переделать.
• Трекинг состояния (xAPI-утверждения + State Resource) обеспечивает возобновление и оценку. Отправляйте утверждение на каждом решении и храните данные в LRS в России.
• Аналитика путей (распределение выборов, частота путей, отвал) и есть отдача от формата; для неё нужны утверждения по каждому выбору.
• Ветвите только ради важных навыков суждения; для передачи знаний квиз или хотспоты обойдутся гораздо дешевле.

Что почитать дальше

• Квизы и опросы в плеере: дизайн и трекинг
• Трекинг видео через xAPI Video Profile
• Что делает видео интерактивным и почему это повышает вовлечённость