1. Identify the target device(s) like IPhone, Android based devices, Blackberry, J2ME based device(s) etc,
2. Identify the Device OS version. e.g. Blackberry 4.6 and 5.0 has very different browser implementations.
3. Does your targeted mobile device browser support the popup window functionality?
4. Does your targeted mobile device browser have iframe or frameset support?
5. Identify the implementation method of SCORM.  e.g. we considered –
   1. JavaScript plus Google Gears API
   2. JavaScript plus HTML 5 database
   3. JavaScript plus native device language
   4. JavaScript plus MIDP profile i.e. J2ME
6. Consider the application’s running mode; will it be
   1. Online: Requires continuous internet connection
      1. You may like to consider intermittent  internet connection while attempting a course
   2. Offline: Doesn’t require continuous internet connection
7. Are you planning for cross platform SCORM player
   1. Currently this is possibly only using a web based SCORM player.
   2. Right now it seems offline applications cannot achieve cross-platform SCORM implementation

Keep these in mind before considering SCROM implementation for mobile devices.

The post Top 7 Things To Consider Before Implementing SCORM For Mobile Devices first appeared on The Upside Learning Blog.

Again, as in implementation of SCORM for mobile devices, we encountered some interesting issues in its implementation for Blackberry.

Find our experience on the same.

Target Platform:

After a good amount of R&D and feasibility study on available device software for Blackberry devices, we selected device software 5.0+ as our target platform. Device software 5.0 has good inbuilt browser support (some of the features are from HTML 5.0) and, also has Widget SDK, which is used to create native applications in HTML.

Implementation:

1. Development tools required:

• Normal J2EE development environment like Eclipse and Java SDK.
• Blackberry Widget SDK: You can get more information about Widget SDK here.

We created a Blackberry Widget, which is a combination of two parts:

• Actual Widget
• Custom JavaScript Extension

• Actual Widget
  • The complete UI of solution is defined (in HTML and JavaScript) in the Actual Widget.

• Custom JavaScript Extension
  • A JavaScript Extension is Java code that is built into a BlackBerry Widget, and can be accessed through JavaScript. This capability allows you to extend the functionality of your BlackBerry Widget application to include native BlackBerry functionality.
  • We used it as a backend of our solution to communicate with online database/LMS.

2. Solution:

• We implemented SCORM standard in JavaScript files. These files were then included in the widget.
• As mentioned before, this was an offline solution hence course content was residing in the device itself. We built JavaScript extension to download the actual course content.
• After launching the SCORM complaint course content, the communication took place with JavaScript files, as it would happen in a normal desktop browser.
• We used Google Gears API to store the tracking information of the user. Google Gears API provides ability to create database/tables which greatly simplify storing of tracking data. It uses the open source SQLite database system. (Note: Recently Google has decided to drop Gears in support of HTML 5 database and Blackberry has also decided to use Google backed webkit in their new device OS 6). To sync tracking data back to online LMS, you can use normal browser based method or you can use JavaScript extension built in Java.
• The widget name, icon image, start file etc. were defined in the config.xml file of the widget.
• The final solution was built using command line (bbwp.exe). Alternatively, you can use Eclipse to build the solution.

3. Problems encountered while trying to implement SCORM for Device software 4.6:

• Online mode:
• There was no problem in running SCORM complaint mobile LMS in Blackberry browser.

• Offline mode:
  • Device software 4.6 doesn’t have widget support, so we had to create everything in native Java language including invoking the browser instance for running the courses.
  • While running the courses we had to manually tell the browser which type of file it is rendering like HTML or JavaScript.
  • Till this point everything seemed fine, but we got stuck at a point where actual SCORM communication occurs, using frameset or iframe. We were not able to make API calls or normal JavaScript calls from one frame to another frame.
  • As yet, we haven’t been able to find any solution to this problem nor do we know if the problem lies with Blackberry.(Blackberry  browser has had a very bad reputation until Device software 5.0)

I hope our experience helps you in implementing SCORM for Blackberry devices. Have you followed some different approach? Or implemented it for Device software 4.6? We would like to hear your experience too.

The post SCORM Implementation For Blackberry first appeared on The Upside Learning Blog.

Mobile devices have limitations:

– Screen size
– Availability of required technology/software like J2ME, a compatible browser
– Availability of consistent internet connection

Considering the limitations the UpsideLMS implemented two types of solutions:

A Web/ Browser Based Solution:

SCROM Implementation Method: JavaScript

• Mobile browsers now almost fully support JavaScript and this makes it possible to implement SCORM using JS support.

• Each mobile device has different configurations and it is always better to identify the device requesting content before rendering the HTML content. For identifying devices we used the information in request headers. Here you will find that there is some variation in each mobile device browser. We used the following variables from the headers to get the device type.
  • User-Agent (Most widely used)
  • x-operamini-phone-ua
  • x-wap-profile
  • x-skyfire-phone

• Ideally when we launch course content from LMS we open it in new popup window, so that course gets its own desirable window size. But while implementing such on mobile devices we encountered that some of the well known mobile device browsers don’t support pop up windows – the Blackberry is an example. So we had no choice but to open it in the base window. Accordingly we made changes in our SCORM implementation to accommodate both conditions. Some of the low level mobile devices browsers don’t support either popup windows and frame structures. If that’s the case, you just can’t run SCORM courses on them.

• SCORM has provisions to track time spent by the user in session. Normally the setTimeOut() function is used to track time. But some browsers don’t support it. If you are targeting such a browser time tracking may not happen.

• Also while coding SCORM implementation try to avoid [advanced JavaScript functions (DHTML, regular expressions)] as each browser has varying degree of JavaScript support.

The web/ browser based solution has a wide reach as every basic mobile handset has a browser but it also has one drawback – it requires a continuous internet connection. This isn’t a problem on a desktop PC as normally they have continuous internet connections. But on a mobile device there is no guarantee of continuous connectivity and this may lead to issues with SCORM tracking .

A Native application solution:
The problem that arises from not having continuous connectivity can be resolved by developing a native application for the mobile device. These days, a SDK is available for almost every mobile device which can be used to develop native applications for that specific device.

SCROM Implementation Method: JavaScript plus mobile device specific SDK

• A native application is an installable application which you download on your mobile device and install. The application can run offline so you don’t need a continuous internet connection. You can synchronize your application whenever required with online databases to download the latest course material and send back tracking information to the LMS database.

• We launch the course in a SCORM player which has SCORM implemented using JavaScript. Here we typically use the native browser instance of mobile device. Also most mobile device SDKs provides some way of accessing JavaScript methods in html page. So from within the native code you can communicate with your course.

• You must take care to ensure the native browser supports
  • JavaScript
  • Popup window or frame structure
  • Advance JavaScript functions

The primary drawback of native application is that you will have to create a separate one for each mobile device as there is no common SDK available and the learning curve for a SDK is steep compared to HTML and JavaScript.

This may give some insights on SCORM implementations for mobile platforms. Have you tried to get SCORM working on mobile devices? What was your experience like? Share it with us in the comments.

The post SCORM Implementation For Mobile Devices first appeared on The Upside Learning Blog.