Posted on: June 30, 2015
It’s always good to look back every now and again, to assess what’s been achieved and what could have been done differently. This is important for organisations as well as individuals.
Alongside that we were working with a global professional body to design the technology underpinning their Continuing Professional Development (CPD) programme.
Experience API (aka Tin Can)
Both of these projects had xAPI at their heart. With the social media organisation, as well as function-specific APIs to allow the front-end to communicate with Moodle, we also used xAPI as the main means to store the learner’s progress and activity.
With the CPD programme, Learning Locker became the primary database for all the user interactions with the system. This meant designing a bespoke implementation of xAPI with a set of function scenarios, each one requiring its own statement design.
Wherever possible, we have tried to make use of standard statement components (such as verbs, activity types and recipes) as described in the xAPI Registry. We also have tried to avoid functions that are specific to a certain Learning Record Store (LRS), such as the custom APIs provided by LearningLocker.
Whilst custom APIs are often really useful ways to solve problems, as soon as you start to use them you are then tied to that particular application. To minimise issues later on if you need to migrate to another application, then you need to stick to the standards as much as possible.
It’s a similar case with the verbs and other statement components. It’s usually far better to use language that is commonly understood, rather than inventing your own language and structures. In our case that wasn’t always possible, but we did make sure that anything that we created specifically was fully documented in a structured specification document - written using git and Markdown.
Git and Markdown
It’s been a really interesting year, so far, exploring how the technologies used by developers can play a part in learning solution design.
Initially this was inspired by the the UK Government Digital Service’s thinking on how they use Github (a distributed version control system) to collaboratively create their strategy documents as well as their code.
Git, at its simplest, is a way of keeping progressive backups (known as repositories) of text files, with the ability to roll-back to any previous version.
More than, this, it’s possible for other members of the team to have their own copies of the Git repository, make changes, and merge those changes into everyone’s versions. It’s quite magical seeing it in operation!
We’ve used Git for managing the version control on documents. It’s so much more robust than sending Word documents by email with version numbers in the file names…
Git does work best on text files - which is where Markdown comes in. It’s a very simple way of specifying formatting (such as headings, bullets and tables) within a plain text file.
Using Markdown allows you to focus on the content, rather than the design - which you can always tweak later.
The Wyver Solutions website is now built using Markdown. Following a major service failure at our hosting provider, we decided to take what was left of our website and migrate to a static site, which has no need for databases and should be far quicker to use than the old Wordpress site.
We’ve built the site using Jekyll and hosted it for free on Github. The basic framework took a weekend to sort out, and now it’s just a matter of taking the old content from Wordpress and converting it to a set of Markdown files. This is made simpler using the Wordpress -> Jekyll exporter plugin, but there’s still a bit of tweaking to do on each page, particularly around images.
In the process, unavoidably we’ve had to lose the links to the old pages, and we’ve now got a new RSS feed URL. We hope this doesn’t cause too much confusion!
It’s been a good process to work through. There’s a lot you can do if you write with Markdown files. From a single, collaborative, version-controlled source you can create a responsive website, a PDF, HTML5 presentation slides or an ebook! We’re looking forward to exploring more…
As well as looking at generic lean principles - like defining the problem statement (harder, and more important, than you think) and the Plan, Do, Study, Act cycle, we also looked at more specific learning-related ideas.
For example, did you know that Lean actually started out in Learning & Development? It began as a programme in the US in the 1940s, called Training Within Industry. Its methods enabled companies to get people productive within weeks rather than years.
TWI focussed on three core areas:
- Job Instruction - how to break down jobs into tightly defined steps which can be taught, observed and coached
- Job Methods - how to evaluate your own job for efficiency, how to suggest improvements by eliminating, combining, rearranging, or simplifying, and then how to “sell” those ideas back into the organisation
- Job Relations - how to deal with workers effectively and fairly
In our consulting work recently we have included a focus on Job Methods and process mapping as well as just the technologies that can help to provide instruction and learning.
Lean is all about working “just in time” and “reducing waste” - ideas which many learning organisations could usefully employ.
We’re looking forward to digging further into xAPI. There are a lot of people now developing real case studies which illustrates its benefits.
We’ll also be exploring more single-source technologies for content development. There are already a handful of high-end applications which do this for commercial publishing organisations. We’d like to identify a toolkit that can be used by smaller organisations with just a small amount of technical knowledge.
And we’ll be picking up more on Lean ideas. Just adding technology to an already convoluted process will not solve all the problems. Improvements in both go hand-in-hand.
If you would like to know more about what we’ve been doing and how we can help your organisation, please get in touch