Tuesday, July 31, 2007

What is a reusable SCO?

If your project requires that you show a SCO is reusable, then your
instructor has made the same interpretation about SCORM as so many other
people. The end result is spending a lot of time creating chunks of
information that when combined may look like a ransom note.

The most reusable SCO would be a page that says "Welcome". Insert an

), and and LMSFinish() on the page. Now you can use this
for every course you have. You can even give the user a score for it.
This is how the tools that claim to create SCORM from Word work. Your
page can now be served from the ADLnet SCORM 1.2 Self-test, and it will
be conformant. However, instructionally, I believe it will be useless.

How about if you argue that re-usability is not a worthwhile objective
when it requires poor instructional design. I believe that
graphics/multimedia, and even items like glossaries (what SCORM now
calls "Assets") should be re-usable. However, I believe that
restructuring a trackable unit so that it is re-usable is a bad idea,
and a waste of time. For example, ask your instructor to re-use your
project requirement to teach people about the re-usability of PDF
content, or PostScript content, or AICC content, or photocopy content.

Monday, July 30, 2007

SCORM - the issue of shareable content

Perhaps we should develop the SFORM specification (Shareable Food Object
Reusability Model). A SFO is the smallest trackable (something you
order from a waiter) unit that you can re-use. OK, so now you serve the
end-user some pepper. Follow it up as the next course with some salt.
The next SFO will be the fish. And so on. This is a highly re-usable
and since you can put it on paper, metal, or porcelain plates, it is
highly interoperable.

If we think of side-dishes, perhaps a SFO makes more sense. But
remember, that under the SFORM specification, the LMS is responsible for
navigation from one SFO to the next. One SFO cannot access another SFO
while it is still open. So the pairing of a good wine with a complex
dish becomes contrary to the specification.

If instead we restrict the "re-usability" part of the SFORM to assets,
it makes a heck of a lot more sense. Serve water with every course of
the meal. A salt shaker (glossary) is provided with each course.
Interoperability means you can serve this meal on a boat, an airplane,
at home, or in a restaurant.

In terms of a "repository", it can be as simple as a folder on a hard
drive containing graphics - if you have a tool to preview each, they
become easily reusable. The course designer has to be intimately
familiar with any object they plan to re-use, or they will produce
unusable content. This whole process needs to be about the learner, NOT
the developer; however, the SCORM specification readers tend to be
developers focusing on their own short-term needs. If the development
tools that these people have are difficult to use (e.g. using Notepad to
create HTML pages), then SCORM takes on the common meaning: I need to do
everything to avoid having to create new content - so I will create very
generic material that I can reinsert into every course. For example:

Emergency Exit Manual
Welcome to this vehicle. In case of a fire, accident, flood, snowstorm,
heat wave, or other emergency, please place your head between your
knees, or crawl to the nearest exit, or wait for a rescuer, or update
your last will and testament. Our
pilot/captain/conductor/autopilot/director/engineer has been
specifically trained on how to use this
boat/plane/car/bicycle/submarine. Thank you for
flying/riding/driving/jumping/shopping with us.

Test: Have you have been properly prepared? a. yes b. no c. all of the

If on the other hand, the developer has a tool that makes it easy to
create and repackage content (e.g. an authoring tool like ReadyGo -
equivalent to PPT for presentation), SCORM takes on much more of a
meaning about interoperability. Reusability is done upstream, during
content assembly/packaging. It takes less than a minute for the
software to repackage an entire course and create the necessary manifest
files. Now the barrier to reusing portions of one course in another
course are much lower, and it becomes easier and more cost-effective to
create coherent, instructionally sound courses driven by learner needs
rather than by developer limitations.

Why isn't "interoperability" part of the name "SCORM"?