Subtitle: To script or not to script...
At the end of last week and the start of this week I focussed on integrating a Piwik no-Javascript web beacon (web bug) with the HTML-RDFa snippet produced by the Creative Commons choose-license form.
This resulted in an initial OER license-tracker, which currently supports OpenLearn-LearningSpace and LabSpace URLs. It makes requests over the Web for RDF files from OpenLearn, and queries the Piwik API.
There is also an oEmbed-API interface to the OER form - to help with automation and batch processing. It is linked to from the OER form (#alt).
Note, there is the potential to extend the OER license-tracker form to, for example, support OER Commons URLs as input, with the resulting license-tracker snippet referencing the source URL at MIT for example.
However, by the middle of the week, we turned our attention to the other strand of the project - CaPReT: Cut and Paste Reuse Tracking. Guy Barrett and I worked yesterday to add the CaPReT Javascript to a Moodle side-block on the OpenLearn-Labspace test server (behind our firewall). Moodle didn't remove the scripts from the sticky block (yay!) and we're almost ready for our first round of technical testing next week.
Guy is proving to be a great resource to review ideas, and he pointed out very reasonably that many downloadable OER archives (plain Zip, SCORM etc.) provided by OpenLearn, MIT (I checked!) and others contain Javascripts. (It should be noted that the RSS feeds provided by OpenLearn don't link to Javascripts.)
Anyway, the emphasis of the Track OER project on no-Javascript tracking may be mis-placed. Using custom Google Analytics Javascript contained in the downloadable packages would remove the probable reliance on Track.olnet.org - a long-term support concern in making the Track OER tools production-ready. (Remember, Track.olnet.org does dynamic server-side processing of the web-beacon request, specific to re-used/ re-hosted OERs, before redirecting to the Piwik web-beacon.)
So, I got busy yesterday and put together a first prototype for a custom Google Analytics Javascript solution. You will need to 'View source' (and/or use Firebug) in your browser to see what is happening...
Which leads to my question - "To script, or not to script...?"
Extra content
Comment 1 by Tony Hirst
Contribute to the discussion
Please log in to post a comment. Register here if you haven't signed up yet.

Tony Hirst
4:46pm 21 August 2012
Nick
For js/no-js, is it worth considering different regimes?
eg I can think of at least the following:
A great advantgae of Javascript is that you can instrument large areas of the web page, not just track usage. TO what extent is the project limited to monitoring resource tracking (in which case thought should be given to ways of maximising how we might track the propagation of links to a resource eg by means of campaign tracking codes appended to URLs, as well as what exactly constitutes a resource: eg a web page that contains an embedded image and a link to a PDF) and to what extent is there also an interest in tracking resource usage (eg not just time on page etc, but also how a page is used, what exit links are clicked on etc).
One way of tracking PDFs is to include links in them that carry a campaign code associated with that PDF. In the simplest case, if i own example.com/resource, I could embed example.com/resource?foo=bar.pdf in bar.pdf and then if anyone clicks on that link I know they came from bar.pdf from campaign tracking analytics on example.com.
This sort of thing also works if you share links by email, or twitter - generate a sharelink with tracking info. (ie this lets us explore not just that a resource is accessed, but also feeds in data about where the link that provided the access came from...)