posted by | on , , | Comments Off on A brief history of LaunchHistory [ies]

SCORMCloud maintains launch history, but so does Bright.

But they are totally different animals.

In SCORMCloud, launch history is recorded, in Bright launch history is ‘captured’.

HUH WHAT!? Yer talking …… MADNESS!!!!

But all kidding aside, what’s the difference [there are lots of Bright blog posts with this theme]?

  • in SCORMCloud, a course has to write its own ‘launch history’ data.  So if its a TinCan course, for instance, there’s no launch history.  Also for misbehaving courses, you may also get no launch history.  In the world of debugging, this can be a big bummer.
  • for Bright, we capture the fact a course has been launched before it happens.  This means that you get launch history for TinCan and you get it even if the course didn’t load correctly.

That’s what I mean the difference between recorded and captured.
So we does the Bright launch history include?   Lots of goodness!  Check it out:

2015-03-19_1549

Now this is just formatted JSON like is returned from the Bright API:

  • id – that’s just an internal reference.  Unlikely to be of much use.
  • registration_guid – for SCORMCloud, that’s the registration ID.  For other types of course providers, the unique ID for that resource.
  • course_guid – for SCORMCloud, that’s the course ID.  For other types of course providers, the unique ID for that resource.
  • learner_id – that’s the user.  Hi!
  • launch_source – what requested the launch; or the client type.
  • http_referer – this is the page we launched off.  It’s the where.  Click it, it should be live!
  • http_user_agent – the holy grail.  User agent.  YES!
  • remote_addr:  IP address of where the launch was requested.  Also highly useful and also not available from SCORMCloud.
  • request_uri: the actual request generated to the Bright server.  Just guts.
  • created_at: when?
  • provider_launch_url: see below

So there’s some REAL magic here in the provider_launch_url.  Since we capture this, we now can provide introspection to running courses.   If they can grab their own location [via window.location from javascript], they can do their own logging by holding onto the window URL and logging it.

You can then backtrack via Bright to the original learner id and registration ID.   Already we’ve built some really amazing tracking with this…. and the possibilities are quite breathtaking.

What’s next?  Recording the registration state before and after the launch.   That will be too cool and will provide great insight.