Авторский инструмент SCORM

Question

Я начинаю новый проект. Целью проекта является создание инструмента электронного авторского права для создания курсов в жалобе SCORM. Я новичок в этой области, и у меня мало идей по этому вопросу. Я ознакомился с инструментом разработки в Articulate, который требуется от моего клиента. Я понял создание контента, но я пытаюсь понять, как я могу экспортировать это как совместимый со SCORM курс? В промежутке я также узнал о xAPI и понял, что это своего рода расширенный SCORM. Может ли кто-нибудь помочь мне понять это,

1) Как создать контент из моего пользовательского инструмента разработки и экспортировать его в виде жалобы SCORM

2) Лучше использовать xAPI или SCORM.

3) Как pacakge SCORM взаимодействует с моей заказной LMS?

4) Слышал про LRS,

Мой пользовательский инструмент авторинга будет создан в React и сохранен в MondDB Любая помощь будет принята с благодарностью. Thankyou!

Answer 1

Это очень много, особенно сразу.

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, помимо того, что включено в спецификацию для API JavaScript.

4) Вы не включили вопрос здесь.

Я бы предложил ознакомиться с двумя наборами стандартов через http://scorm.com и http://xapi.com.. И хотя это штекер для продукта моей компании, вы можете рассмотреть драйвер Rustici как есть. продукт (библиотека), специально разработанный, чтобы упростить для инструмента разработки возможность экспорта контента в виде SCORM 1.2, 2004, AICC, cmi5 или Tin Can (последние два - xAPI). После того, как ваш инструмент будет запущен и работает с минимальной поддержкой стандартов, вам следует рассмотреть возможность тестирования его на Rustici SCORM Cloud (это бесплатно для этой цели), см. http://cloud.scorm.com.

Answer 2

Похоже, вы говорите о разработке редактируемого контента; и сам контент "рамки". Это огромное усилие! Это огромная поддержка! Тем не менее, люди делают это.

Построив систему CMS для многих вспомогательных предметов, мне пришлось разделить и победить эту задачу.

Несколько способов подумать, чтобы переварить этого зверя - данные, данные, данные

1. Требования к видам деятельности (виды взаимодействия)
2. Дизайн (статический / динамический) для этих взаимодействий
3. Вид / вид фасада могут измениться. Техник движется со скоростью света. Нужно придумать супер надежную модель данных.
4. Я бы подумал о том, как они могут быть общими и как их можно расширять для удовлетворения целей / потребностей клиентов. Все зависит от того, сколько настроек может произойти (если есть).
5. Я начинаю сопоставлять все это вызовам уровня объекта SCORM CMI. Оценка, прогресс, взаимодействие, задачи и т. Д. *
6. Получите собственную библиотеку API содержимого SCORM или напишите ее самостоятельно. Вы будете повторно использовать многие из этих вызовов, нет смысла встраивать их во все ваши взаимодействия
7. Встаньте на SCORM Packaging .. большая часть этого должна быть определена во время автора. Много чтения и множество функций, которые вы должны использовать, если ваши клиенты даже используют. Не занимайтесь разработкой в ​​местах, где рыночная потребность составляет 0,1%. Низко висящие фрукты доставят вас на рынок.
8. Окружите себя страстными великими людьми. Они вам понадобятся

Что касается стандартов, то все дело в мобильности. SCORM работает напрямую с LMS, если именно туда отправляется ваш клиент. Другие используют LRS, которая закодирована для работы с той, которую они установили во время автора. Вы даже можете сделать оба.

Помимо React и MongoDB, вам понадобится что-то, что может поднимать и сдвигать весь этот контент.

Answer 3

Формат огромный, кратких справочников нет. И разные инструменты авторинга имеют разную глубину поддержки scorm. Вероятно, вам следует начать с этого документа