Dan Marsden’s thoughts on the SCORM Cloud + Moodle plugin make me feel like we’ve done exactly that.

With the availability of the Rustici engine at an affordable price, the urgency for getting the SCORM module in Moodle SCORM 2004 compliant/certified has definately decreased.

Context: Dan contributes a great deal to Moodle’s codebase, particularly in the area of the SCORM module. He knows his Moodle stuff and he knows his SCORM stuff.

If you use Moodle and you’ve ever had cause to consider SCORM 2004, I think Dan’s message is pretty compelling.

How would you get started?

Moodle mod + directions available here.

SCORM Cloud signup available here.

Thanks to Dan for taking the time to check out our work. He offered some comments that are spot on, of course, and we’ve taken those to heart. We’ll release those changes later this week.

If not, the changes are as follows:

PAYMENT

2. You will be billed on the day you elect to move to a paid account and subsequently on that day of each month.

Why? Well, we didn’t want to charge you for Oct 1 – 27 if you opened your account on Oct 27. So, we just keep up with “your month” instead of “calendar months”.

4. Overages will be charged for each registration over your chosen price plan tier in accordance with our pricing set forth on our website.

Why? We wanted to offer the option of allowing for overages on your accounts. Some people will elect to block overages, and will receive a message indicating they’ve crossed the limit of their plan and can’t offer training anymore. Others will allow for overages, but they have to pay for the overages at month’s end.

5. All fees are exclusive of all taxes, levies, or duties imposed by taxing authorities and you shall be responsible for payment of all such taxes, levies or duties, if applicable.

Why? 5 is the old 4. Nothing new here. But now there’s a 4, so this is a 5. Exciting.

TERMINATION

2. If you cancel the Service before the end of your current paid up month, your cancellation may take effect immediately and you will not be charged again except for overages for the current month which will be charged at the end of that monthly period.

Why? Since we added overages as a concept, we have to have the right to charge them after you cancel. We wouldn’t want you trying to take advantage of us, now would we?

So, that’s it. Nothing too exciting here. We’ll continue to fight to keep this thing as short as we possibly can!

The SCORM Cloud, of course, is a different beast. It’s run on a set of servers we control, and we’re able to very quickly evolve the product and release those changes into the wild. Today, we’ve introduced a couple of changes that might be useful for you. (For more specific details, visit our forums.)

• Skins: If you want the player to look like your own, now you can provide a CSS reference to control the look and feel.
• Redirection options: You’ve always been able to specify the destination on exit, now you can use a few built in options (like “close the window”)
• Data Export: This is a big one. Your data is, well, your data. We’ve known that all along, we’ve just made it a lot easier for you to export that data.

Lastly, we’ve introduced the SCORM Cloud console. As of this moment, you can create your own app_id (FREE for a trial), check on your usage, export your data, just about anything necessary to manage a Cloud account. We hope that you find the SCORM Cloud so useful that the paid accounts are appealing!

If you’re having any performance problems with the SCORM Engine, we have good solutions for you. This article in particular gives the details.

These fixes are easy, fast, and reliable. And they have a substantial impact on performance for SQL Server customers in particular.

Lastly, you may all feel free to mock me for the fact that our “optimized” option is, in fact, slower than our “non-optimized” option in many circumstances. (Whereas the “Ask us anything” invitation on the website is sincere, please be so kind as to restrict your mocking of me to this particular topic. I don’t like to be seen crying at the office.)

For the first “arc” of development on it, we’ve been entirely focused on the user experience. We want to be sure we’re creating something that is notably different from LMSs that disappoint and profoundly useful. Short of that, there’s not a lot of reason to commit the energy this will inevitably require.

Without further adieu, we’d like to ask you to click around in our completely mocked up “reportage”. (You’ll notice that the data doesn’t change and that many of the things that look clickable really aren’t. We’ll ask you for some contact information on the way in, but nothing more. We would love for you to dig into the reports and give us any and all feedback. If it sucks, tell us that. If it would be endlessly valuable to you, tell us that too.

• What are we missing?
• Are there views of the suggested data that would be more useful?
• Should we arrange the data differently?
• Is there something you want to know that isn’t there?

If you’d like to check it out, check it out here.

ADL avoided overly specifying exactly how developers should implement SCORM. This was a wise decision. It led to innovation and wide-spread adoption. But when this freedom was abused, it also led to incompatibilities, headaches and it even led some people to proclaim that SCORM sucks. We are, quite frankly, getting a little tired of people blaming the standard instead of holding their vendors accountable.

ADL can’t and shouldn’t recommend specific vendors. Its position is that the market will reward the good and punish the bad. Free markets are great, but they are most effective when coupled with information. For a market to reward the good and punish the bad, its participants need the be able to effectively distinguish between what is good and what is bad. Up until now, there has been very little information to help purchasers distinguish between good SCORM and bad SCORM. That’s where “SCORM for RFPs” comes in.

This new e-book provides at least 27 questions you can ask your LMS vendor about their SCORM implementation. It covers everything from the basics (”Are you actually SCORM certified?”) to the technically advanced (”How is SCORM data exchanged between the client and server?”).

This paper is meant to be a stake in the ground, a starting point to the discussion. It is our opinion of what constitutes a robust SCORM LMS implementation. We hope that others will have additional thoughts to add and we welcome debate about the points we have made. We have enabled comments on the e-book download page, please post your thoughts there for everybody to see.

Don’t feel like reading the 33 page e-book, skim over our one page summary, or watch Susan cover the highlights:

7 critical questions to ask your LMS vendor about SCORM from Rustici Software on Vimeo.

Today, I’m focusing on particular technical choices at runtime, rather than packaging or “process”. (If process were part of this, I think all five things would be “test your content”.) Without further ado:

1. Find the SCORM API well

Once a piece of SCORM content is launched, its first task should be finding the SCORM API. Without this API, it can’t communicate with the LMS at all. (And a piece of SCORM content that can’t communicate with an LMS is just a webpage with annoying popup error messages…)

Finding the API isn’t a trivial task. It can be located in a parent frame or a parent window. This distinction is a crucial one, and isn’t tested well by the SCORM test suite. If your content adheres to the standard, it will perform well either in a frameset or in its own window. Take the time to get this right, or you’ll suffer the pain of fixing it when you send your content to the second LMS you want it to work in. (And for goodness sake, we’ve provided you with the code for an improved API discovery algorithm. Go ahead and use it. All of you.)

Lastly, if you can’t find the API, be sure to tell the user. The user needs to know right away that they won’t be getting credit for any of the work they’re doing.

2. Set your status right away

The first thing a piece of content should do with the API after it finds it is call GetValue(cmi.completion_status). [Note: This article is not about syntax. I'm intentionally avoiding committing to a version of SCORM.] If the current status is “not attempted”, it’s crucial that the content change it to “incomplete” right away. If the content fails to make this change, the LMS is obligated to consider the content complete on exit, even if it isn’t!

3. For the love of your users, use bookmarks

I suppose this is the least crucial of the elements in this missive, but please take care of your users! SCORM offers a simple concept of bookmarking (cmi.location). As your learner progresses through your content, set a bookmark periodically. Then, when the learner returns, be sure to give them the opportunity to return to where they left off. You would expect that level of courtesy in any piece of content you take, so provide it to your learners.

4. Record completion

The vast majority of SCORM content is taken at the encouragement of another. In a corporate environment, training is pushed on learners for compliance reasons. In the education world, professors often want to know that the learning material has been reviewed. In many ways, SCORM is largely about tracking the completion of training.

The only way the LMS knows that the learner has completed the training is if the content tells the LMS that the learner completed the training. Please tell the LMS.

5. Exit gracefully

top.window.close() is not the right way to exit from a piece of SCORM content. Is that clear? Sometimes, content is opened in its own window. If this is the case, then top.window.close() will probably be just fine. Sometimes, content is opened in a frameset. If this is the case, the world will come to an end.

Section 2.1.3 of the SCORM 2004 3rd & 4th Edition Specs puts it like this:

If the window in which the SCO was launched is a top-level window (i.e., the
window has no parent window, but it has an opener) then the SCO may attempt to
close the window after calling Terminate(“”).

[...]

If the window is not a top-level window (i.e., the window has a parent window),
the SCO may not act on the parent window or any window in the chain of parents.
For example, a SCO is not allowed to attempt to close the top window, unless it is
its own window.

This is one to get right. As an LMS vendor, content that obliterates the entire LMS (by closing its window) is annoying both from a user experience perspective and from a data perspective (in poorly implemented LMSs). Put simply, don’t trash the room on your way out the door.

________

These five things alone won’t make your content conformant, but they will move you a long way down the path to creating interoperable, well liked content. So, what did I miss? Are these things the top 5?

We are making configuration settings for our new LMS ([redacted]) and one of the questions is:

1.3.5. How is the overall score for a SCORM course with more than one SCO computed? With the following choices:

• MaximumScore. Highest score of all items (SCOs) in the course.
• AverageScore. Average score of all items (SCOs) in the course.
• FirstScore. The first score achieved by the user across all items (SCOs) in the course. Note: If this option is selected, ScormScoreUpdateOption should be set to “Never” and the user’s score will always remain the first score they achieved.
• MostRecentScore. The most recent score achieved by the user across all items (SCOs) in the course.

What do you recommend?

My first reaction

Well, clearly we’re talking about an LMS that is really SCORM 1.2 centric. This ability to manage scores across attempts and SCOs is one of the things that SCORM 2004 actually does very well. Rollup rules allow the content author to specify these behaviors in great detail, including weighting the various elements and even excluding some. This provides the author with useful tools such as pre-assessment that doesn’t impact overall satisfaction.

My second reaction

There simply is not a good answer to this question. If these settings are global, as they appear to be, I can’t be forced to pick one in particular as it wouldn’t serve other situations adequately. The most common multi-SCO package structure, to my mind, is a course with several SCOs and a single post test (assuming we’re dealing with more than one score). I’m not sure that any of these options serve that package structure well at all.

My ultimate conclusion

An LMS simply can’t afford to make singular decisions about how to deal with content. It absolutely has to provide configurability on a package by package basis. Failing to acknowledge that the world of content is widely varied will lead to content that doesn’t work as desired. This, frankly, is why building an LMS with SCORM conformance is so difficult to get right.

How we handle it in SCORM Engine and SCORM Cloud implementations

Package properties provide our ability to address different pieces of content differently. (Take a look at the possibilities. There are more than 50 options for configuring a course. All are defaulted intelligently, but all are also the answer to a question that has to be answered for certain courses.)

Take a look at how we’ve approached the particular problem of rolling up scores in SCORM 1.2. We have options that aren’t unlike those offered in the question above. The differences are relevant, but only to a degree. Fundamentally important, though, is that you can set these properties for each package.

I hope this provides a bit of illustration as the level of detail required to really nail the SCORM problem. We suffer this minutiae so our customers don’t have to.

Note: Don’t worry, my recommendation for the person who sent the question isn’t as obtuse as, “Use the SCORM Engine”… We’re still chatting via email…

Today’s question relates to the pricing tiers described here. We chose to go with a tiered pricing structure because we like to buy stuff that way. Our costs for Zendesk are fixed… we’ve picked a tier that accommodates our usage, and we don’t have to think about each ticket carrying a cost. It’s fair to them, it’s fair to us, we’re happy.

There’s a little difference, though. With the pricing of the SCORM Cloud, it’s possible that you would have a month in which you would hit the limit of your tier. So, what should we do with that? Should it be a hard and fast limit? We don’t think so. We think that you, the customer, would want your customers to be able to continue training. So we have to decide how to deal with overages.

We want the overage policy to be fair, but also to be something that doesn’t get us taken advantage of. So here’s the conclusion…  Up through “The Big” plan, which includes 300 registrations per month, each registration beyond your chosen plan will be charged at $3.

______________

Update (later on the 5th): Our Ombudsman, Troy, called me out for the “cliff-like” ending to the original version of this post.  I would try to argue, except, well, he was right.  In setting the overages, we were shooting for something fair to both parties.  We didn’t want something that was overtly penal, but we wanted to respect the tiered structure as well.  So we went with $3.  Truth be told, Mike and I argued about it until David was annoyed, and then we just decided.

And so I close with this… I thank each and every one of you for taking the time to read this post.  If our thoughts on overages seem wrong or unfair, please do email me at tim.martin at scorm.com.  If my failure to close the original version of this post disrupted your life in any way, I do apologize.  It was deeply irresponsible of me.

There are other times, though, where the words are important and also broadly applicable. The SCORM Cloud Click Through Agreement definitely falls in that group, as it will be a core platform for us and others going forward. It’s not a one time thing. So when someone comes to us with a question about it, we’re open to addressing it broadly, on behalf of all customers.

A prospect pointed out this section of the agreement to me recently. He mentioned that this would be a potential show stopper for them, due to the risks it afforded.

Rustici, in its sole discretion, has the right to suspend or terminate your account and refuse any and all current or future use of the Service for any reason at any time.

Point 3 under Termination, in the document dated July 23, 2009

My reaction? Well, yeah, he’s right. That would be a substantial risk to someone looking to build applications around our service. I get that. So I went looking at some of our favorite, thoughtful companies.

37signals, in its sole discretion, has the right to suspend or terminate your account and refuse any and all current or future use of the Service, or any other 37signals service, for any reason at any time. Such termination of the Service will result in the deactivation or deletion of your Account or your access to your Account, and the forfeiture and relinquishment of all Content in your Account. 37signals reserves the right to refuse service to anyone for any reason at any time.

37signals, Basecamp Terms and Conditions

Hmm, well, that’s pretty aggressive, and a bit like ours. The crux of the issue for us, as the provider, is that we can’t commit to provide this service forever, can we? We have to have the ability to stop providing this down the road if we’re incapable of doing it in a way that makes money (or worse, if we cease to exist for some reason).

We may suspend your right and license to use any or all Paid Services (and any associated Amazon Properties) other than Amazon FPS and Amazon DevPay, or terminate this Agreement in its entirety (and, accordingly, cease providing all Services to you), for any reason or for no reason, at our discretion at any time by providing you sixty (60) days’ advance notice in accordance with the notice provisions set forth in Section 15 below.

Amazon’s, AWS Customer Agreement

Alright, this makes more sense. Provide some notice, but don’t obligate yourself forever.

So, our new language will require of us that provide notice, unless, of course, you fail to pay or breach the agreement in some other fashion. Without further adieu, here’s our new language:

Except for your breach of the agreement, including without limitation failure to pay, in which case Rustici may immediately terminate the Agreement or suspend your account, Rustici, in its sole discretion, has the right to terminate your account and use of the Service for any reason upon sixty (60) days notice.

Rustici Software, SCORM Cloud Terms of Use

So, our thanks go out to a prospect who was willing to call us on something that was unfair. Provided you are willing to use “reasonableness” as a guide like we are, feel free to let us know when we miss something important. We’ll do our best to accommodate.