Авторский инструмент SCORM
Я начинаю новый проект. Целью проекта является создание инструмента электронного авторского права для создания курсов в жалобе SCORM. Я новичок в этой области, и у меня мало идей по этому вопросу. Я ознакомился с инструментом разработки в Articulate, который требуется от моего клиента. Я понял создание контента, но я пытаюсь понять, как я могу экспортировать это как совместимый курс SCORM? В промежутке я также узнал о xAPI и понял, что это своего рода расширенный SCORM. Может ли кто-нибудь помочь мне понять это,
1) Как можно создавать контент из моего пользовательского инструмента авторинга и экспортировать как жалобу SCORM
2) Лучше использовать xAPI или SCORM.
3) Как пакет SCORM взаимодействует с моей заказной LMS?
4) Слышал про LRS,
Мой пользовательский инструмент разработки будет сделан в React и сохранен в MondDB. Любая помощь будет принята с благодарностью. Спасибо!
3 ответа
Это очень много, особенно сразу.
1) Спецификация SCORM состоит из нескольких частей. Существует часть упаковки и часть времени выполнения. Основой является то, что ваш пакет должен быть zip-файлом, и этот zip-файл должен включать в себя определенные файлы, которые указывают LMS, какой это тип стандарта, наряду с другими метаданными о пакете. Для SCORM это будет называться imsmanifest.xml файл. Для xAPI вы, скорее всего, собираетесь использовать cmi5.xml (см. CMI5) или tincan.xml файл (что экспортирует Articulate Storyline, когда он говорит "xAPI"). Другие части пакета будут зависеть от того, на какой стандарт и версию этого стандарта (для SCORM 1.2, 2004, 2-го, 3-го или 4-го издания) вы нацеливаетесь, понимая, что разные LMS поддерживают разные стандарты и разные степени этих стандартов.
После создания пакета, который будет импортировать, самому контенту (обычно HTML-файлу) потребуется найти JavaScript API, предоставляемый проигрывателем SCORM (из LMS), и выполнять конкретные вызовы в зависимости от того, что контент нужно хранить или прочитайте, это часть времени выполнения. Звонки снова будут зависеть от стандарта и версии. Для пакетов на основе xAPI (либо tincan.xml пакеты или пакеты cmi5) контент будет напрямую передаваться в LRS на основе информации, предоставленной в URL во время запуска (встроенный JavaScript API отсутствует).
2) Это полностью зависит от того, как выглядит ваша клиентская база и типы данных, которые вы собираетесь собирать. SCORM является более зрелым ландшафтом и имеет более широкое распространение и более конкретизирован, если информация, которую вам нужно собрать, вписывается в его ограниченную информационную модель, тогда это все еще отличный выбор. Если вам нужна значительная переносимость данных и / или информация, которую нужно собрать, выходит за рамки данных о соответствии (пройдено / не выполнено, выполнено и оценено) и / или данных о взаимодействии (вопросы + ответы), тогда вам следует рассмотреть xAPI, в частности, через cmi5.
3) LMS должна предоставлять API-интерфейс JavaScript (указанный в среде выполнения SCORM), который контент будет использовать в качестве своего интерфейса. Хранение / извлечение данных зависит от конкретной реализации для LMS, помимо того, что включено в спецификацию JavaScript API.
4) Вы действительно не включили вопрос здесь.
Я бы предложил ознакомиться с двумя наборами стандартов через http://scorm.com/ и http://xapi.com/. И хотя это плагин для продукта моей компании, вы можете рассмотреть драйвер Rustici, поскольку он представляет собой продукт (библиотеку), специально предназначенный для упрощения создания авторским инструментом контента в виде SCORM 1.2, 2004, AICC, cmi5 или Консервная банка (последние два xAPI). После того, как ваш инструмент будет запущен и работает с минимальной поддержкой стандартов, вам следует рассмотреть возможность его тестирования в SCORM Cloud от Rustici (он бесплатный для этой цели), см. http://cloud.scorm.com/.
Похоже, вы говорите о разработке редактируемого контента; и сам контент "рамки". Это огромное усилие! Это огромная поддержка! Тем не менее, люди делают это.
Построив систему CMS для многих вспомогательных предметов, мне пришлось разделить и победить эту задачу.
Несколько способов подумать, чтобы переварить этого зверя - данные, данные, данные
- Требования к видам деятельности (виды взаимодействия)
- Дизайн (статический / динамический) для этих взаимодействий
- Вид / отображение фасада могут измениться. Техник движется со скоростью света. Нужно придумать супер надежную модель данных.
- Я бы подумал о том, как они могут быть общими и как их можно расширять для удовлетворения целей / потребностей клиентов. Все зависит от того, сколько настроек может произойти.
- Я начинаю сопоставлять все это вызовам уровня объекта SCORM CMI. Оценка, прогресс, взаимодействие, цели и т. Д...
- Получите себе злую библиотеку API содержимого SCORM или напишите ее самостоятельно. Вы будете повторно использовать многие из этих вызовов, не имеет смысла включать их во все ваши взаимодействия
- Встать на упаковку SCORM.. большая часть этого должна быть определена во время автора. Много чтения и множество функций, которые вы должны использовать, если ваши клиенты даже используют. Не занимайтесь разработкой в местах, где рыночная потребность составляет 0,1%. Низко висящие фрукты доставят вас на рынок.
- Окружите себя страстными великими людьми. Вы будете нуждаться в них.
Что касается стандартов, это все о мобильности. SCORM работает напрямую с LMS, если именно туда отправляется ваш клиент. Другие используют LRS, которая закодирована для работы с той, которую они установили во время автора. Вы можете даже сделать оба.
Помимо React и MongoDB вам понадобится что-то, что может поднять и сдвинуть весь этот контент.
Формат огромный, кратких справочников нет. И разные инструменты авторинга имеют разную глубину поддержки scorm. Вы, вероятно, должны начать с этого документа