TRACK OER - Project Plan

Cloud created by:

Patrick McAndrew
10 October 2012

The project plan aas set out in the proposal is structured on a development plan that will start immediately the project is funded to establish the code base, review use case and engage with the developer community. The majority of work in the development cycle will take place later to fit with planned availability of development effort which has been agreed with line management prior to submission of this proposal. There will be two parallel strands.

Strand 1: Track OER – web-bug tracker

  • At the heart of most Web analytics systems, including Google Analytics, Piwik, ComScore and the analytics part of CaPRéT is what is termed a web-bug – code attached to an image, often a one-pixel by one-pixel ‘hidden’ image. By virtue of it’s inclusion or embedding in a host Web page it can be used to log data about the host page, the visitor, and the visitor’s browsing software. The image link can pass back information, taking the form for example:
  • <img src= "" alt="" />
  • Google Analytics, Piwik and other systems wrap a web-bug in a Javascript library, which makes the analytics system easier to implement, more flexible, and adds extra data about the visitor that is only available via Javascript (for example, screen resolution, support for Flash and Java, etc.).
  • The dis-advantage of the Javascript wrapper is that it is not available or is dis-allowed in interfaces like RSS feeds, Zip and packaging standards (eg. SCORM, IMS Common Cartridge), and is often stripped out because of security concerns when imported into content management and online learning systems.
  • Given this overwhelming restriction, no-Javascript web-bugs were researched in collaboration with Scott Leslie of BCcampus as part of the OLnet project (http, and code was released ( This code was developed as an example prototype to demonstrate the principles. It is not currently functional and will form the basis for extension in this project. While web-bugs are usually linked to one-pixel hidden graphics we will associate the tracking with the embedded Creative Commons graphic.

Strand 1: Development steps

  1. The code base will be extensively reworked to provide a working service linked to an appropriate analytics system such as Piwik. Piwik is an open-source alternative to Google Analytics implemented using Javascript, PHP and MySQL. It provides similar tracking, visualization and reporting functionality, and is highly extensible. Whereas Google Analytics is a hosted solution, Piwik can be installed and customized on a local server ( (Expected effort 15 days.)
  2. Installing/implementing a web-bug in B2S LabSpace: It is suggested that test no-Javascript web-bugs can be manually added to the RSS feeds and downloads/ archives for the two B2S modules available via Labspace ( This is a low-risk approach that will be useful for evaluation. The software will then undergo Full-scale implementation across OpenLearn would be a more complex proposition. (Expected effort 10 days/5 days testing.)

Strand 2 CaPRéT++

  • As the name suggests Cut and Paste Reuse Tracking (CaPRéT) is designed to add attribution and license meta-data, and to track the informal copying and pasting of OERs. It has been developed by Tatemae and MIT Office of Educational Innovation and Technology, and the code is available via Github ( &
  • CaPRéT comprises two parts. The client-side consists of Javascript libraries built on top of jQuery. The server-side part is a Node.js application, which uses Hummingbird for realtime visualizations (

Strand 2: Development steps

  1. Currently CaPRéT does not appear to track when an individual image or multimedia resource is copied from within an OER. This limitation can be reduced using HTML5 DOM extensions within CaPRéT. (10 days)
  2. Installing/ implementing CaPRéT, in LabSpace and Moodle: The CaPRéT Javascript libraries have already been implemented in a Drupal 6.x blog ( and a Moodle 2.0 system ( In both cases, there was no need to install plugins or extensions on the server - they were implemented as custom blocks (the implementor needs super-user/administrator privileges on Drupal and Moodle). Given this initial success, it is thought that the CaPRéT Javascript can be added to LabSpace in a low-risk manner, and within the constraints of the OpenLearn development and release cycle, for evaluation with the B2S course content. (10 days)
  3. Moodle version of CaPRéT: As part of the project, a CaPRéT plugin will be written for Moodle to go through acceptance testing for full inclusion in OpenLearn/LabSpace. (10 days/5days testing)
  4. Overall testing and documentation in accordance with requirements (10 days)


Extra content

Embedded Content


Contribute to the discussion

Please log in to post a comment. Register here if you haven't signed up yet.