eラーニングの仕様の中心となるものは、相互運用性です。よくできていると思いますが、私たちは、いくつか改善の余地を見つけました。Tin Can APIは、現在の仕様に残る、多くの相互運用性の問題解決を図ります。しかし、私たちは、落とし穴を見つけるには、あなたの支援が必要です。
ユーザーインターフェイスの問題
LMSは、すべて独自のユーザーインタフェースを持っています。可能な限り多くLMSと互換性を持たせたコンテンツを作成する場合、LMSが持つユーザインターフェイスの、すべてのバリエーションを考慮することは、必ずしも可能ではありません。Tin Can APIでは、ユーザインタフェースを、コンテンツ/アクティビティ側にゆだねます。こうすることで、コンテンツ/アクティビティの開発者が意図したとおりに、そのコンテンツが経験されるよう保証することができます。
内容の提出（送信）
Tin Can APIでは、学習者にとって「提出（submit）」とは、
「終わりました（I’m done） これを提出して評価される準備ができている」という意味です。
SCORMには、「提出完了（submitted）」や「提出しない（not submitted）」という概念がありません。（「サスペンド（suspend）」は、入りません）SCORMを使用する場合、データの損失を避けるために自身をサスペンドする必要がありますが、コンテンツが完了してから、サスペンドした場合、LMSはコンテンツが評価される準備ができていると判断します。
もし、LMSが、評価される準備ができたと判断せず、学習者が戻り、完了したコンテンツを見直したい場合はどうなるでしょう。TinCan APIは、LMSが完了・提出で起こしかねない想定すべてを取り除きます。この問題は、「提出完了」または「提出しない」の概念を導入することで解決できます。学習者がコンテンツを完了したことや、提出する準備ができていること、または、コンテンツを完了し戻りたい、提出して評価される前に、見直すといったことをLMSは、判断することができます。
シーケンシング
SCORMでは、LMSで、シーケンシングを行うことは難しく、混乱しやすいです。Tin Can APIは、完全にLMSからシーケンスを取り除きます。LMSは、正しくシーケンス処理をしていないことより、それ以上に相互運用性に問題があります。コンテンツ/アクティビティは、単独で動作します。もし、それがコンテンツ開発者のもとで動作すれば、誰であっても動作しなければなりません。
APIのシンプルさ
一般的に、Tin Can APIは、不明瞭な領域を減らすことができます。推測に頼ることがずっと少なくなります。LRSは推測や想定に頼る必要はありません。全て、明記されており、そうあるべきです。ここでのTinCanAPIの弱点は、動詞の変化ですが、それにはいい解決法を考えています。もうひとつの弱点は、異なる方法でレポートしたユーザーが、本当は同一ユーザだと識別する処理が、LRSに対して負担が増してしまうことです。これは、「activity definitions agreement(アクティビティ定義の合意）」に関することで、それに私たちも、解決法を提案しています。
※ この記事は、CC BY 3.0のもと、Rustici Software 社の記事を翻訳したものです。
http://scorm.com/tincancapabilities/project-tin-can-phase-3-better-interoperability/
ホーム