H5P and the Common Cartridge

Over the last few weeks I've been having a look at H5P, a rather nice way of creating interactive content that can be embedded in Moodle or Drupal. One of the strengths of H5P is that the information to edit a piece of content is included in the distribution of the content, however this also means that the server side part of a full H5P implementation is fairly complicated, as it needs to support editing. As a way of learning more about H5P, I started creating my own implementation, and quickly realised that in practice very little is needed on the server side for a pure delivery system.

This got me thinking, could an H5P module be included in an IMS Global Common Cartridge, allowing it to be deployed on any LMS/VLE? A secondary advantage of packaging H5P modules like this would be that they could be embedded in text pages to make interactive textbooks - something that is currently not possible with the Moodle implementation. (I think it might be possible to use H5P on Drupal to provide modules in iframes to be included in Moodle book or lesson activities, but I've not tried it.) I also have a strong preference for open interoperable standards for content - while Moodle book and lesson are open source, and their backup versions are simple enough to decode, they're not really intended as interoperable content types.

So, what is needed to get an H5P module into a CC package?

H5P modules are written in JavaScript, using the JQuery library, and will also include CSS, so the page header includes the script tags to include JQuery, some H5P core code and the module specific code and links to the CSS files. The H5P data is included as a JSON object called H5PIntegration, which also includes paths for Ajax and the H5P root. The Ajax actions are optional, though required is the user state or outcomes are to be stored. As the Common Cartridge specification does not support any server side code, my implementation leaves the Ajax fields blank. The H5P root setting is a slight problem, as it is relative to the server root, and there is no fixed path for deploying common cartridge. In addition to this path, each individual H5P activity also has a path to its content, relative to the server root. To fix this, I added an extra small bit of JavaScript which creates the H5PIntegration data, adding in the path at runtime.

  <script>
    H5PIntegration2 = {...};

    function PrepareH5P()
    {
         path = document.location.pathname.split('/').slice(0, -1).join('/');
         H5PIntegration2.baseUrl = path;
         H5PIntegration2.url = path + "/h5pdata/";
         for(var cid in H5PIntegration2.contents)
         {
             var intid = cid.substring(4);
             H5PIntegration2.contents[cid].url = path + "/h5pdata/content/"+intid;
         }
         H5PIntegration = H5PIntegration2;
    }

    PrepareH5P();
  </script>
With this JavaScript added, provided the script and CSS includes have relative paths, the page is compatible with the Common Cartridge, and supports H5P activities.

So far I've only done a proof-of-concept experiment with one simple H5P activity, however I see no reason why this technique shouldn't work with any activity that doesn't depend on user data being stored on the server.

What next?

Over the next few weeks I'll try and tidy up the code I used to generate the Common Cartridge, and extend it to support multiple H5P activities per page, and multiple pages. Once it's in a suitably usable form, I'll stick it online, and probably also on Github so others can play with it.

In the longer term it would be really nice to have an extended version of Common Cartridge that supported minimal server side rules, something comparable in power to QTI response processing, but able to interact with any HTML page. I think that would be sufficient to support session storage and outcomes from H5P activities, or other JavaScript interactions. It would also provide a way of creating properly interoperable material equivalent to Moodle lesson, though (hopefully) less constrained.

I recently was shown a Runestone Interactive book, "How to Think Like a Computer Scientist: Interactive Edition" by Jeremy Singer, who is using it as the text for a L1 Computing Science module.   Interactive books like these can be linked from CC packages using LTI, and for now that is the way to do it. However  a platform neutral interoperability format that could support open interactive textbooks like these within the VLE, that could be remixed by teachers to suit their needs would be a very useful thing.