The Publishing Project

Further thoughts on xAPI: cmi5 and beyond

Now that we have an LRS, a library to handle xAPI statement generation, and upload to the LRS let’s look at some further thoughts on xAPI, cmi5, when to use it, and when not to use it. The first thing we need to do is figure out when is xAPI the best solution for our project. Some of the questions I would ask to help through this process: Are we reusing existing content or are we creating brand new material? Is all the content in an LMS or are we using content from external sources? Are we using SCORM to

SCORM and xAPI

One of the hottest things, when I was working in higher education, was SCORM. It provided a way for courses coded and packaged to the SCORM specification to send data to a Learning Management System for it to be tracked and recorded. Jump to 2010 when Rustici Software began the first research into SCORM 2.0 with the specification reaching a 1.0 release in 2013 and becoming first the TinCanAPI and, eventually, the Experience API (xAPI). xAPI is based on Activity Streams (and its corresponding draft RFC) and provides an education-focused extension to the activity streams specification so, in theory, we

Using a web worker to publish Markdown

Inspired by Surma’s article When should you be using Web Workers?, I’ve been looking at ways to use web workers on my projects and I think I’ve found a good candidate. I write in Markdown and, until now, have had to rely on the build process to generate HTML files from the Markdown. It works but it requires rebuilding all the files whenever I add new content. The idea is as follows: The page will create a worker The worker will convert the Markdown to HTML and process syntax highlight commands The worker will return the processed content to the

More Display Goodness

The CSS Display Module Level 3 has added new ways to tell browsers how we want to layout and display the content on our pages. We still have block, inline, none, and other values for display that have been available since CSS 1.0 back in the 1990s. The new features include a two-value version of the attribute. .container { /* these are equivalent */ display: block; display: block flow; } display outside: The outside container value The <display: outside>, the first value in the two-element display declaration, defines the outer display type, meaning the type of the outer box container.

Working with Jetpack in development mode

Plugins like Jetpack don’t work at all in development environments that don’t use a fully qualified domain name or a domain that uses non-standard local domains (like site.local or site.dev), making it impossible to use any of its features unless we use Development Mode. To enable development mode we need to define the JETPACK_DEV_DEBUG in wp-config.php. The code looks something like this: <?php define( ‘JETPACK_DEV_DEBUG’, true ); While in Development Mode, some features will not be available since they require WordPress.com for their functionality, for example, Related Posts and Publicize. Other features will have reduced functionality to give developers a