SOAP for SCORM

At DevLearn 2010, Ben Clark and I presented a session named SOAP for SCORM on behalf of LETSI. The topic was the LETSI Run-Time Web Service (RTWS), a proposed modification of SCORM to use SOAP for communication rather than the current JavaScript model. I presented the first half of the session, covering the basic “what” and “why” ideas while Ben covered the technical “how” details in the second half.

This blog post is my attempt at documenting my portion of the session. Bear in mind that there was a lot of Q&A from the audience, and much of the session was ad-libbed. The descriptive text presented below may not exactly match was what in the session, but the gist is there.

If you’re interested in the nitty-gritty technical details, check out the Developer’s Guide on the LETSI website.

The Presentation

SOAP for SCORM: Linking Training Apps to Your LMS with LETSI's Run-time Web Service (RTWS)

 

Learning Education Training Systems Interoperability

Some quick background information on the LETSI organization.

LETSI stands for “Learning Education Training Systems Interoperability”.

LETSI believes in pushing training systems forward through agile, iterative software development. Make things quickly, get feedback, and make changes. In our current Internet age, we don’t have the time to take years developing a spec. Make something that works, then turn it into a spec.

LETSI believes in engagement with standards bodies and vendors throughout the process. If a new technology is to become mainstream, it’s vital to get vendors in on the action. Make them stakeholders and get them involved in the project at an early stage.

Unlike some standards bodies, LETSI is transparent and open — there are no strings attached. Membership is not limited to corporations or agencies. Want to have a say in the future of training technology? Join LETSI and you could be on the conference call next week.

 

What is the RTWS? An alternative to JavaScript

Simply stated, LETSI’s Run-time Web Service (RTWS) is a replacement for the SCORM JavaScript API. There are some other features that go beyond SCORM 2004, but the bulk of the RTWS is focused on replacing the JavaScript communication system with a SOAP system.

 

SCORM API: A JavaScript object in a web browser window

The current SCORM architecture requires that courses be launched in a frameset or pop-up window.

 

Course pop-up window communicates with LMS browser window via JavaScript

The course frameset/window contains a JavaScript-based API that communicates with the parent frame/window (the LMS website).

 

LMS browser window communicates with LMS server/database via JavaScript and server-side scripting

The LMS website typically performs data gets/sets on a database using a combination of ajax (xmlhttprequest) and server-side scripting (PHP, ASP, Java, etc.).

 

LETSI Run-time Web Service: A direct connection between the course and the LMS via SOAP (XML)

The LETSI RTWS changes the architecture to eliminate the middleman (the LMS website), allowing the course to directly communicate with the LMS backend using SOAP. (SOAP can be loosely described as XML sent via HTTP requests.)

 

What does this mean? (and why should I care?)

 

No more dependence on Web browsers

Replacing the JavaScript API with a SOAP system means the course no longer needs to be launched from the LMS. If the course is no longer required to be launched from an LMS, the web browser itself becomes optional, enabling the course to be launched from a variety of environments, including mobile apps, desktop apps, hybrid Web/desktop apps such as Fluid, Prism and Adobe Air, and other software solutions such as virtual worlds and serious games. This effectively makes SCORM’s CMI data model available to almost every software/web-based training solution.

No dependence on the web browser also means the course content can be hosted anywhere, and is no longer required to be stored in the LMS system.

Note: In some prototypes, the course must be launched from the LMS for the first attempt. This is due to registration requirements that are still being ironed out.

 

Better security

The JavaScript API has long been the weakest link in terms of security; it’s easy to hack and can’t be encrypted. Replacing the JavaScript API with SOAP (XML served via HTTP/HTTPS) enables courses to use discreet, secure communication via HTTP POSTs, similar to banks and other sensitive systems. RTWS courses will be protected via a combination of a shared key (a hash stored in both the LMS and the course’s code), user name, user ID, and a secure password incorporating SHA-1 encryption.

IMPORTANT: Since the shared key and the password are contained in the course’s code, the course will only be secure if the developer keeps it secure. For example, using JavaScript to handle your SOAP calls will make your data viewable to the client. If you keep all of the SOAP work behind the scenes using server-side code, your course will be much more secure.

 

Better accessibility

The accessibility benefits of the LETSI RTWS are debatable, but here are some of my personal beliefs about how the RTWS can make a course more accessible:

1. Since the RTWS discards the SCORM JavaScript API, a web-based course can be built to run without without a single line of JavaScript (traditional form POSTS and server-side code can process the SOAP requests). I’m not saying JavaScript is bad, but it’s a fair assumption that in most cases pages that don’t require JavaScript are more compatible with alternative browsing devices.

Also, as a developer, I know first-hand that when JavaScript is *required* for a course, many developers feel they’ve been given carte blanche to go hog-wild with JavaScript; for example, they might use it for interactive widgets that require a mouse (not keyboard accessible) and dynamically update/generate page content using ajax (difficult for screen readers and braille displays). These situations are problematic for people who use assistive technology; by eliminating SCORM’s JavaScript requirement, we can force developers to take a closer look at why and how they’re using JavaScript, hopefully leading to a more accessible course.

2. No reliance on web browsers means a course can be built in a desktop app or other environment that may (or may not) be more accessible than a web site or Flash movie. Of course, this is completely up to the developer, but the possibilities are there if the developer chooses to go down that path.

 

Less restrictive development environment

Under the LETSI RTWS, courses no longer need to be uploaded to the LMS and can be stored on ANY web server. There are several useful byproducts of this:

1. Course manifests no longer need to list every course asset. (Manifests are still required because they contain core data about the course, including the shared secret.)

2. If you’re a course vendor, you can maintain control of all of your course materials and simply provide a link and manifest to clients. No more ZIPs!

3. Since the course materials remain on your server and are not required to run on the LMS server, you’re free to use server-side code (previously a taboo in SCORM).

 

What’s the catch?

 

Requires more work

Despite their often negative reputations, LMSs provide a key service for your SCORM course: a SCORM API with error-checking (including error/debug messages) and behind-the-scenes handling of the CMI data model for you. The RTWS is not currently equipped to provide detailed error messages regarding the use of the CMI data model; if you choose to use the LETSI RTWS in place of the SCORM API, you will no longer have the benefit of the SCORM API’s error messages.

In the RTWS each ‘set’ request is an XML document created by your course and submitted to the server via HTTP. Since your course is creating and submitting the XML, it must use its own logic to determine if there are any errors, such as malformed XML or misuses of the CMI data model. For example, if your course accidentally tries to set a read-only field such as learner_name, you will not receive any error messages. It is up to your course to ensure the specifications of the CMI data model are being followed.

(Hopefully in the near future there will be 3rd-party libraries or frameworks that will provide this logic for you so you won’t have to write your own.)

Also, your course must be using a technology that supports SOAP.

 

Only supports single-SCO courses

The RTWS currently only supports single-SCO courses, and does not support SCORM 2004’s Sequencing and Navigation rules.

On a related note, since the content is being abstracted from the LMS, the LMS’s SCORM “player” will not be available to the RTWS course.

 

http://letsi.org/rtws

You can read more about the RTWS at http://letsi.org/rtws

Reminder: LETSI membership is open to the public. If you’d like help shape the RTWS (or other LETSI projects), join us!

Additional notes and tidbits not covered in my portion of the presentation

  • I briefly demonstrated a prototype I created for Flash-based courses. My prototype uses a modified version of my pipwerks SCORM ActionScript wrapper, allowing developers to simply swap out the pipwerks SCORM class file with a new pipwerks LETSI RTWS class file and still have their course behave as it did with SCORM 2004. This prototype is not available to the public yet, but when I’ve worked out the bugs I will be sure to post a blog entry about it. Stay tuned!
  • The LETSI RTWS is based on the SCORM 2004 (4th Edition) spec and uses the same CMI data model.
  • Because the RTWS uses a new launch approach, support for querying the course’s attempt history has been added to the data model (see GetAttempt and GetAttemptList in the RTWS documentation).
  • Unlike SCORM, a Get request in the RTWS returns the entire data set in an XML file. It’s up to the course to parse the XML and extract the value for a particular CMI element. I’ve whipped up a document mapping the CMI elements to their XML equivalents.
  • A Set request can be partial (set a single or small group of elements) or complete (set the entire data model).
  • SCORM’s Initialize() and Terminate() methods are not currently used in the RTWS.
  • Rustici Software (scorm.com), Booz Allen Hamilton, and Meridian are all creating LMS prototypes that support the RTWS.
  • Rustici Software hopes to fold support for the RTWS into its SCORM Cloud service once the RTWS is ready for prime-time.
  • The ADL (owners of SCORM) are not involved with the RTWS, but they are aware of its existence and are monitoring the situation. In a separate action, the ADL is requesting input on the future of SCORM via Project Tin Can. It is LETSI’s hope that the RTWS, when ready, will be folded into the ADL’s plans for SCORM and that the two will co-exist peacefully.
Advertisements

DevLearn 2010 Recap

And so ends another whirlwind of a week known as DevLearn.

Could the timing have been any better? My San Francisco Giants (yes, my Giants!) won the World Series and decided to have the largest parade in San Francisco history on the first day of DevLearn. It just happened to be a block from the conference site, which was A-OK with me! In their honor, I wore my Giants jersey the entire day.

In a quirky turn of events, I also wound up being a speaker at DevLearn this year, alongside Ben Clark of Rustici Software. We co-presented “SOAP for SCORM“, an introduction to the LETSI Run-Time Web Service. Aside from the requisite technical glitch, our session went well, and we had a great group of attendees.

Update: Here’s a separate blog entry covering our SOAP for SCORM presentation. Major thanks to Avron Barr, LETSI, Ben, and the E-Learning Guild for the opportunity.

As with any conference, each year there are always some outstanding sessions, and always a few duds. Being a tech guy who happens to have an MA in instructional design (as opposed to an instructional designer who happens to do some tech) I’m usually disappointed by the lack of in-depth technical sessions. This year was par for the course. There were some very good high-level sessions on technical topics, such as the introduction to DITA, but nothing particularly deep. Again, I’m a tech guy and perhaps not the main target of the conference; most attendees appear to be subject-matter experts, trainers, or instructional designers who happen to do their own technical work. DevLearn is a very good fit for this demographic.

I particularly found Ginny Heenan’s session about quantifying billing rates and handling the business side of e-learning very useful, and thought Koreen Olbrish’s session was a great primer on some of the latest and greatest technologies.

My favorite moment? Probably Richard Culatta‘s ‘six-minute perspective‘. Funny, very well-written, excellent slides, and most of all, great points. Inspiring in a very TED-esque way. Nancy Duarte would have been proud.

My least-favorite moment? Probably Allen Interactions’ Zebra after-party/demo. DevLearn was heavily branded with the Zebra theme, and it looks like Allen Interactions paid some big big marketing bucks this year. They were trying very hard to make it feel like an industry-changing event. I don’t begrudge them of their marketing efforts. However, it ruffles my feathers that Allen Interactions required everyone to sign a non-disclosure agreement before they could attend the main demonstration — they had already demoed much of the same material in the Expo hall without requiring the NDA! Makes. No. Sense. Then the demo itself failed to live up to the immense hype. I’m not sure what I’m allowed to say because of that silly NDA, but let me leave it at this: Zebra looks perfectly useful, but the demo was hokey and the entire dog-and-pony show was very tiring. (Sorry, guys, just calling it like I saw it. But thanks for the cupcakes, and my daughter loves her new toy zebra!)

Update 11/10/2010: Allen Interactions has sent an email to attendees providing more information about the NDA:

We have been asked what can and cannot be said about Zebra with respect to the Nondisclosure Agreement (NDA). Several product features we demonstrated and discussed at the event were still in the process of patent application. As these applications have now been filed, you are free to share any information about Zebra you heard or saw.

Doesn’t really change my opinion, but now I can tell you: the very first live demo they performed was creating a page-turner. Literally! It was a photo album with next and back buttons. Zebra may very well revolutionize the industry, but it won’t be because of the hokey DevLearn demos.

Speaking of vendors, Open Sesame probably had the greatest marketing ploy of the entire conference: they gave away free black hoodies with their logo on the back. They also gave you a key. If they spotted you wearing the hoodie at the conference, they’d give you a chance to see if your key unlocked their box. What was in the box? A free iPad, of course! There were tons of folks wearing Open Sesame hoodies and talking about their company. Very clever!

Sessions and vendors aside, in my mind, the true value of DevLearn is the informal learning and networking that occurs in hallway conversations. Putting faces to the people you know on Twitter. Meeting people who do what you do but in a different part of the world. People who share your excitement about a topic that your mom doesn’t understand.

One unexpected treat was meeting some of the folks who use my pipwerks SCORM wrappers. Since the wrappers are free and don’t require any kind of registration, I usually have no idea who’s using them. It’s very gratifying to meet developers who have successfully used the wrappers in their projects… it feels great to know that the wrappers have been useful. Thanks for coming to talk to me!

Of course, I can’t list every person I ran into this year, but suffice to say I had some great conversations with old acquaintances and people I had just met, including Brian Dusablon, Ben Clark, BJ Schone, Gary Hegenbart, Aaron Silvers, and many, many more. Being an introvert, I’m usually uncomfortable in social settings, but this year was quite fun. Guess I’ll have to do it again next year.

Speaking of next year, DevLearn 2011 is scheduled to take place in Las Vegas at the City Center. Maybe I’ll get to check out the death ray in person!

DevLearn 2009 Recap

(Okay, I admit it… this post is WAY overdue.)

Let me begin by saying this is not a rant, but rather an honest account of my impressions regarding this year’s DevLearn.

Nearly two months have passed, and when I think of DevLearn I think of two things: Social media gone wild, and hallway conversations.

Social Media Gone Wild

DevLearn 2009 was absolutely wonderful if you’re into incorporating social media into e-learning. Or should I say “using social media for learning,” without the “e.”

Unfortunately for me, I’m not really interested in using social media for learning. I mean, I learn via social media all the time — Twitter and RSS feeds are a raging river of information flooding my head with ideas every day. But when it comes to creating e-learning projects at work, we’re not ready for social media. It doesn’t really have a place in our plans yet, and we’re A-OK with that.

So upon attending DevLearn, you can guess how dismayed I was about the lack of breadth regarding session topics… it seemed as though every other session was about social media. Perhaps the conference should have been named SoMeLearn.

I believe this was my fourth DevLearn conference — I live nearby so it’s not difficult to attend — and I’d have to say this one felt the lightest when it came to the Dev part of DevLearn. There were so few hands-on technical sessions that I had a hard time finding them. I know I’m not the only person who felt this way, as a number of folks confided similar sentiments. Chad Udell, one of this year’s presenters (probably the best technical session I attended) had [link no longer available]:

[T]he conference wasn’t all rainbows and unicorns for me. There are some real underlying problems I have with the conference’s overwhelming love affair with Social Media or Web 2.0 or whatever you may want to call it. […] Do we really need 5-6 sessions about “Leveraging Twitter in your Learning Organization”? […] Given that Mark Oehlert so masterfully managed the Social Learning Jam as a dedicated area for discussion about using Social Media for learning in the eneterprise, it seems a tad silly to have so many concurrent session on the topic.

I may be cast out by talking so candidly about this, but here’s the crux of it for me: If the conference really is called “DevLearn” shouldn’t their (sic) be more “Dev” in the schedule?

I wholeheartedly agree, Chad. I have nothing against social media and finding its place in learning, but did it have to steal so much focus from other areas? Despite my MA in education, I consider myself a developer first and foremost. I like to get my hands dirty. I want more “developy”-type sessions, especially considering the price of the conference. This is meant to be constructive criticism… hopefully next year DevLearn will have a more rounded/balanced session lineup.

Hallway Conversations

Returning to the positives, it was wonderful to meet so many people in person. I’ve “known” many people via Twitter and the blogosphere for quite some time, but it’s a real trip to meet these folks in person. Janet Clarey had a nice post about it (great to meet you, fellow introvert!). In fact, if there was anything about Devlearn 2009 that really stood out for me, it was how great the hallway conversations (and after-parties) were.

Gary Hegenbart said it nicely in his DevLearn recap:

Almost everyone I met included their Twitter name as part of the introductions. […] Twitter accelerated the conversation because if you just met someone you follow or who follows you, then you already knew a lot about the person.  It felt like a reunion and conversation flowed easily and freely.

It was absolutely awesome to finally meet The Beard (aka Aaron Silvers) in person, even if we never really found much time to chat. (Does this guy command a crowd or what? I should start calling him “The Mayor.”) And it goes without saying that if Brian Dusablon and Steve Howard are in the house, we have to hit a pub for a beer and a chat! In my case a Coke since I had to commute an hour by car. Sad, I know.

I learned firsthand that (Mark Oehlert + Kris Rockwell + Koreen Olbrish) === instant mischief. This time it was zombie mischief. LETSI’s Avron Barr was there, and I had the pleasure of driving Mike Rustici to the airport (sorry if I scared you with my crazy driving!). I could go on and on. I’m something of an introvert, so I may not have seemed very excited, but trust me, it was fun.

Following BJ Schone’s footsteps, here’s a list of tweeps I chatted with (apologies if I left you off the list, it wasn’t intentional):

Adobe E-Learning Products “Sneak Peeks”

Today’s Adobe Summit had a session named “Sneak Peeks.” It was (unofficially I think) mentioned that the Adobe E-Learning Suite is coming, and will include Captivate 4, Flash, Photoshop, Acrobat Professional, Device Central, and more.

Here’s a quick list of topics covered.

Versions of Dreamweaver and Flash in E-Learning Suite will NOT be same as those in CS4 suites, and will include e-learning specific bits.

No date for E-Learning Suite given; will only say 2009.

Captivate 4 will include:

  • Automatic panning that follow your screen actions.
  • Previewing in Device Central
    • Allows you to preview on an actual mobile device
    • Allows you to preview with fake screen reflections
  • Inline text editing for captions (no more dialog boxes)
  • Basic drawing tools (shapes)
  • Integration with Adobe Bridge
  • Import > Photoshop files (PSD)
    • Can flatten layers or choose to have them import to separate layers
    • Converts each layer to hi-res PNG
    • Allow syou to animate layers individually on a single slide
  • Support for custom variables, such as using a person’s first name throughout the course
    • Uses $$variablename$$ syntax
    • Means you can use custom static variables throughout a course
    • You can customize an external RDL file to templatize variable use; means you can instruct Captivate to automatically insert variables when recording a demo without having to manually edit the recording afterwards
  • Support for Flash widgets
    • Will work much like components in Flash Professional
    • Captivate 4 will ship with many widgets (including source FLA)
    • Widgets can be customized, and users can create own from scratch
    • Can talk to Captivate (including quizzes) and retrieve variables
    • Example: certificate widget can display person’s name, score for course, date, etc.
    • Example: “perpetual buttons” widget that customizes navigation (forward/back) for movie; hides “back” biutton when on first slide, hide “next” button when on last slide
    • Captivate Exchange on Adobe site will be available for users to post and download custom widgets
  • Support for multiple actions on a single slide
  • Support for ActionScript 3 (can publish to AS2 or AS3 depending on user settings)
  • Can create image slideshow
  • Ability to show/hide toolbar during a course without using customizations
  • Captivate 4 will be on Windows, but work will soon begin on a Mac version
  • Can publish directly to PDF (embeds SWF into new PDF file)
  • Single-SWF output (all files are embedded into single SWF, including nav and full-motion recordings)
  • Auto-generation of Table of Contents (embedded into SWF)
  • SWFs are searchable (text caption content is searchable)
  • “Aggregator” feature allows you to add external Captivate SWFs to project (package multiple SWFs together… is a SWF that loads other SWFs)
  • Supports Flash Player 7, 8, 9 & 10
  • “Reviewer” feature allows users without Captivate to comment on a Captivate SWF
    • Uses Adobe AIR
    • Synchronizes comments form multiple reviewers
  • Supports placeholders to demonstrate where content will be, such as an FLV that isn’t available yet.
    • Helpful when using Reviewer feature so others can know what you have planned
    • Placeholders make it easy to insert content when it becomes available
  • Improved Support for PowerPoint imports
    • Support for dynamic link to PowerPoint presentation — if PowerPoint file is updated, changes wil be reflected in Captivate file
    • Makes PPT file a smart object; you can open and edit PPT file via Captivate (just like how smart vector objects in Photoshop open in Illustrator)

DevLearn 2007

Today was the day… I gave a presentation at the eLearning Guild’s DevLearn 2007 conference in San Jose. Topic? Captivate-to-Flash ActionScript Communication. Not a sexy title, I know, but there was a pretty respectable turnout… which indicates to me that a lot of people want to use Captivate but are feeling quite frustrated with its limitations.

I had a few technical glitches with the laptop and projector (Murphy’s Law, I suppose), but otherwise all seemed to go well. The audience was very receptive and had some great questions. I even managed to give a little plug for SWFObject.

While working on this DevLearn presentation, I realized I have an awfully lot of Captivate-related stuff (scripting how-tos, demonstrations, blog posts, etc.). So much, in fact, that I decided to dedicate a new section of my website to Adobe Captivate. You can find it at http://pipwerks.com/lab/captivate.

I’m still trying to fill out the content and smooth out the wrinkles, so please bear with me. Hope you like it!