underlying assumption regarding SCORM seems to be that you are using an
LCMS and that you want to do output-side reuse (rearranging existing
compiled content rather than recompiling the course). Frankly, this
will not work. How many times do you take printed documents (especially
with each line already numbered) and physically cut/paste them to create
a new document? Taking the built course modules and trying to cut/paste
them into a new course is exactly the same process.
Reusability works when you can create a new document based on previous
assets. I am using the word "assets" because this is the SCORM term
used in SCORM 2004. I think the "asset" idea for sharing is much more
sensible than the SCO idea. There are assets that you may want to use
among several SCOs (e.g. a multi-page glossary, a page of FAQs, a single
graphic). This concept was missing from SCORM 1.2. Reuse among courses
should generally be done at the asset level, rather than at the SCO level.
The tool I work with (ReadyGo) is designed so that you can easily re-use
a sub-page, a page, a chapter, an entire course, a FAQ page, an
individual test question, a look-and-feel template, a glossary, a
certificate template, a tracking configuration, etc. Notice that
"look-and-feel" and "tracking configuration" can and should be re-usable
and transferable independently of the content. While not technically
"content", the content would be un-usable (or just basic text) without
them, and they should be viewed as components of the course equivalent
to text or individual graphics.
The re-use process consists of selecting of copy/pasting from one course
to another within the authoring tool from the outline view (or as
Christie mentioned, from the TOC). Then, you regenerate the course,
thereby creating content with a consistent look and feel, consistent
page numbering, a new table-of-contents, etc. (In ReadyGo, the
appearance is generally separate from the content, thereby allowing much
greater re-use.) With an LCMS approach, re-use consists of rearranging
components that are already built, possibly using different authoring
tools, different appearances, etc. This can easily result in disjointed
"ransom note" courses.
The SCORM philosophy will work best if we go back to its original
purpose which was to ensure that you could re-use existing (compiled)
content from one LMS to another; not from one COURSE to another, or from
one authoring tool to another. Right now they are caught between trying
to ensure that a course will work well on any LMS (therefore, it pretty
much has to be static) and the Web 2.0 concepts of content aggregation
in real time from multiple sources (thereby breaking LMS-independence)
Note that the LCMS approach may even be negative - can you move your content from one LCMS to another, or to another LMS, even as already-built SCORM modules?
People are much more efficient when they use input-side reusability
(prior to generating/printing - as exemplified by desktop applications)
rather than output-side (LCMS SCO reuse/physical paper cut/paste).
Otherwise, we'd see a lot more adoption of server-based presentation
(equivalent to MS-PPT), document (equivalent to MS-Word), spreadsheet
(equivalent to MS-Excel), project tracking (equivalent to MS-Project)
tools with output-side reusability.
No comments:
Post a Comment