Reliance on SCORM Dependence on Java

Today we are continuing our series on what is holding back large-scale mLearning deployment. Before we begin this discussion, we need to address those of you who are up on the current happenings surrounding SCORM. Some of you are aware of Project Tin Can and how it represents the “next-generation eLearning specification”  (http://scorm.com/tincanoverview/) and will provide the means for tracking mLearning content.  While not explicitly stated, this has apparently come to be regarded as a replacement for the SCORM model, which begs the question, what happens to SCORM 1.2 and 2004 if Tin Can is implemented? Intriguing thought, but probably not for this post.

Tin Can represents a way to track mobile learning, but it takes a long time to go from a specification to large-scale adoption, which isn’t ideal since our customers are searching for something they can do today.  Swept up by the rise of iPads and smart devices, the pressure is on providing a migration path, enabling immediate online access to the content.

While there is a lot of discussion about “real” mobile learning, our customers are frantically searching for ways to provide mobile access to content stored in their LMS’s. As LMS’s enable mobile login capabilities, the question quickly turns to “Why can’t I launch the course from my iPad?”

Great question. Why can’t they launch the course, and why does the current SCORM model prevent mobile access? Let’s take a look.

The main reason the course can’t be successfully launched via a mobile device is because every LMS we have ever worked with (e.g. Plateau, Saba, SumTotal, etc.) launches a SCORM course using a Java Applet, requiring the client to install Java. Unfortunately, most mobile devices (especially iPads and iPhones) don’t support Java. Game over.

Why is this holding back mobile learning overall?

First, many eLearning developers and customers rely on content being delivered as a SCORM package; so naturally, many authoring tools publish SCORM packages to load their content into the LMS. As a result, providing mobile access can be a difficult task for both tool vendors and custom eLearning developers.

Somewhat ironically, because of this industry-wide standard, mLearning’s growth has been severely hindered, as organizations can’t simply flip a switch to enable mobile access to the content.

The second major issue is lack of education. This shows up in numerous conversations where a customer requests that a) all their content be published as a SCORM package, and b) that it is accessible using mobile devices. The conversation about Java supportability quickly follows!

What’s the solution?  The most effective way to address this issue is to bundle SCORM, AICC, Flash, and HTML5 into a cohesive package.  Publishing “for mobile” or “for desktop” is fine, but most customers we deal with need both and having to manage two courses in the LMS opens a new can of worms.  As implied, we must figure out how to best render the course (e.g. Flash for some users, HTML5 for others) for a given user on their device.  By bridging both worlds (desktop/SCORM with mobile) organizations can move ahead and fully embrace mobile…today.

 

 

About these ads

Tags: , , , , , , , , , , ,

About CourseAvenue

Visit us at www.CourseAvenue.com

3 responses to “Reliance on SCORM Dependence on Java”

  1. timpmartin says :

    Thanks for the mention of Tin Can here. I’ll spare you my optimism about Tin Can and its fast adoption for now.

    I wanted to comment a bit on the java issue you bring up. I’ll agree with this, several LMSs use Java applets to handle their SCORM communication, and this is 100% a mistake on their part. As you mention, Java creates problems on mobile devices and on browsers with varied support. But using Java for your SCORM communication is a CHOICE made by the LMS creator.

    There are plenty of LMSs that don’t use Java for this. Any LMS that uses the SCORM Engine (including the GeoLearning part of SumTotal, and Blackboard, and learning.com, and Healthstream, and PureSafety, and a pile of others) can launch content effectively on a mobile device. There are plenty of LMS providers who don’t use SCORM Engine too.

    The core problem, though, is that a lot of content uses other technology that isn’t well suited to the devices in question. Flash, obviously, creates problems on iOS devices, and is used by several authoring tools. Screen size, too, is poorly addressed by authoring tools.

    I’ve heard about LMS vendors (Plateau) blaming “SCORM’s reliance on Java” for many of their problems of late. SCORM itself _doesn’t_ rely on Java, but some LMS vendors do.

    • CourseAvenue says :

      Thanks for your input/insight.

      re: Plenty of LMS’s that don’t use Java for this…

      You mention the GeoLearning (part of SumTotal) & Blackboard LMS’s then mention Healthstream & PureSafety. For clarification, we consider Healthstream & Pure Safety (not sure about learning.com) as different than Geo/SumTotal or Blackboard as they are vertical applications of an LMS. In other words, we don’t see people buying the “Pure Safety LMS” like the would say GeoLearning or Blackboard. If Geo and Blackboard don’t have the Java dependence, this mitigates the issue for their users (or their VAR’s).

      re: problem is not SCORM but how it was implemented by the LMS vendors…

      Agreed.
      And as stated in our post, most/all of the customers we deal with use LMS vendors that did use Java to implement SCORM so they are stuck.

      re: Blaming SCORM for their [the LMS vendor’s] problems…
      Agreed as well and if they are blaming SCORM, well, that should not be.

      re: Big issues are authoring tools, Screen size, Flash, etc.
      Also agree.
      That is why we built a Universal Mobile player that scales the screen to fit the device and the ability to launch 1 course with both a Flash-based and HTML5-based technologies (and intelligence to know when to show which one). More to follow on this topic/our solution in coming posts.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 661 other followers

%d bloggers like this: