Decisions To Be Made With SCORM Navigation

Hello,

So we’re still actively working on Hakase SCORM Course Builder.

Now we’re at a point where we have to make some hard design decisions. The current one comes from the bug we found recently, and some of it comes from some new development we’re implementing.

In the next version (cobalt-1.2.0) we’ll have some more Hakase Objects available. Specifically – navigation objects. The first set are internal to a course. You’ll see

  • [next]
  • [prev]
  • [page #]

With the new theme 2 (we’re not so good at our naming conventions here) it means you’ll be able to create your own internal navigation with no menu on the left or next/prev at the bottom. Our test implementation is like a choose-your-own-adventure style of course. Completion is still defined as visiting the last page (but that’s another discussion for later.)

Our next set of navigation controls is a SCORM 2004 4th Edition feature for jumping to another SCO. (Part of the confusion of SCORM is its terminology. We try to stick to how Hakase SCORM Course Builder works and the terms it uses – but sometimes we need to be technically specific.)

For us, a course and a SCO are almost always the same thing. But not always, and this is where the confusion comes in. Take for example this package. (This is from version blackjack-1.1.4 so in newer versions, it will look different.)

one package, two courses

 

Here we have one course, but by definition two SCOs, and we have to ask ourselves, is this a reasonable design? Probably not. But being who we are, we have to test everything. Actually, it’s more likely that you’d see this design

two complex clusters and a final course

which still isn’t very good design. You don’t need to duplicate the Welcome course at the start, it might look correct here but it’s quite confusing for the end user. Or you might see something more like this

complex package with clusters

This is a reasonable design – have a minimum of 3 clusters required, then you can put a test in course conclusion and you’re kind-of-done. But it’s still confusing, because if the user completes course two in cluster A, they may have to complete it again in cluster B if they want to do course three.

And so here’s the dilemma in our design – SCORM 2004 4th Edition navigation actually works on clusters (well, items, but we don’t use that terminology here), not courses (i.e. resources). So if I have a navigation request to jump to course two, which one should it go to? The one in cluster A or cluster B?

And that’s the problem. It’s not impossible to code up. But it’s … difficult. This is how the design looks now:

Hakase Object for navigationBased on the package one from the beginning, there’s only one course to link to, but which one? By definition they’re both clusters and there’s no difference in the cluster name at the moment, so that doesn’t help.

So we have two choices:

  1. Not allow a course to be used more than once in a package. This actually seems reasonable, but will then stop some interesting package and cluster designs.
  2. Change the navigation object to jump to the cluster > course link.

The second option is probably what we’ll go for since it allows for richer interactions with clusters. But if you name your clusters and courses the same then it’s going to be confusing for you as a designer.

So be good with your naming.

Jim
CEO, Tetsuwan Technology
We love learning.

Posted in Blog.