Стандарт xAPI для автора онлайн-курса: какие события нужно согласовать

Небольшая школа передаёт корпоративному заказчику учебный тренажёр. Заказчик хочет получать сведения о попытках в своей системе и спрашивает о поддержке xAPI. Ответ нельзя свести к наличию кнопки экспорта. Сначала нужно понять, какие действия будут фиксироваться, откуда поступят данные и какое решение заказчик собирается принимать по отчёту. Рассмотрим подготовку такого разговора со стороны автора содержания.

Опишите задачу, ради которой нужны данные

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

Например, если ученик отправил ответ, но ещё не получил проверку, его не следует автоматически считать успешно завершившим упражнение. Если достаточно существующего отчёта LMS, отдельная интеграция может оказаться лишней. Сначала определите пробел в данных, затем выбирайте технологию. Для общих показателей можно опереться на материал о подсчёте прохождения курса, сохраняя различие между активностью и результатом.

Разберите роль сообщения и хранилища

xAPI описывает обмен сведениями об учебном опыте между системами. В обзоре разработчика инструментов xAPI ключевыми элементами названы сообщения о действиях и Learning Record Store, сокращённо LRS. Базовая структура сообщения выражается через участника, действие и объект: кто что сделал по отношению к чему. LRS принимает и хранит такие сообщения, а отчёт требует согласованного использования данных.

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

Согласуйте словарь событий

Для первого упражнения составьте таблицу словами, даже если пока не знаете структуру технического сообщения. Для каждого события запишите действие ученика, момент фиксации, объект и ожидаемый смысл. «Открыл упражнение» наступает при начале работы; «отправил ответ» — после принятия ответа системой; «прошёл проверку» — после выполнения согласованного критерия.

Уточните пограничные ситуации. Считается ли завершением простое нажатие последней кнопки? Как различаются попытки одного человека? Что происходит после исправления ответа? Для нашего тренажёра первая неверная попытка и последующая верная должны оставаться различимыми. Если разные инструменты используют одинаковое слово для разных действий, общая диаграмма может выглядеть убедительно и при этом объединять несопоставимые события.

Уточните версию и границы интеграции

Попросите техническую команду назвать поддерживаемую версию и показать документацию обеих сторон. Репозиторий спецификации ADL явно отмечает находящуюся там версию 1.0.3 как прежнюю и направляет к xAPI 2.0. Поэтому ссылка на знакомый пример из старой статьи не подтверждает совместимость конкретных систем сегодня. Версию фиксируют в требованиях и проверяют на выбранной реализации.

Отдельно обсудите запуск учебного материала, идентификацию участника, доступ к данным и получение отчёта. Не путайте эти решения с упаковкой курса SCORM: вопросы могут пересекаться в проекте, но название одного стандарта не заменяет описание другого. На дату подготовки статьи в Umhub не реализованы встроенная отправка xAPI и LRS; их наличие здесь не предполагается.

Подготовьте маленький сценарий приёмки

Возьмите один учебный объект и отдельного тестового участника. Запланируйте первый вход, неверный ответ, исправление, завершение и повторное открытие. До проверки запишите ожидаемые события. Затем попросите техническую команду сопоставить фактические записи с действиями, а заказчика — показать их в том отчёте, ради которого начат проект.

Добавьте повторное нажатие кнопки и временный разрыв связи. Нужно выяснить, как реализация обращается с повторной передачей и потерянными событиями; не обещайте устойчивость по одному успешному прохождению. В проверочном наборе используйте условные данные. Автору достаточно видеть понятный протокол действий и результатов, ему не нужно переносить секреты подключения в учебную методичку или переписку с учениками.

Зафиксируйте результат до расширения проекта

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

Для небольшой школы разумно начать с одного нужного отчёта. Добавление десятков событий без ясного назначения увеличивает объём согласования и затрудняет интерпретацию. Хороший результат подготовки — короткое задание, по которому автор, разработчик и заказчик одинаково понимают, что произошло с учеником и как это должно отразиться в системе. После этого можно оценивать сроки и объём интеграции.