Track OER - midweek status, 16 August

Cloud created by:

Nick Freear
16 August 2012

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

Embedded Content

Contribute

Tony Hirst
3:46pm 21 August 2012


Nick

For js/no-js, is it worth considering different regimes?

eg I can think of at least the following:

  • someone views a resource on a site we own (eg OpenLearn): this may or may not support Javascript...
  • someone downloads a resource and then views it in a browser; the user may or may not have disabled javascript. How about users with particular accessibility settings? Do these interfere with javascript and/or images (ie how might accessible browsing interfere differently with different tracking styles? WHilst there is likely only trace usage by users with strong accessibility support requirements, it would be a shame if further sampling error was introduced becuase tracking and accessible device requirements mismatched.
  • someone takes the content and incorporates it in their own site either literally or in an iframe. Javascript may be stripped or it may not. The host page may be running its own analytics, either Google Analytics or some other variant.
  • the content is syndicated into a reader environment that strips js.
  • someone shares a link to a resource via social media or eg email. In this case, I'm wondering whether tracking information might also be minted into a a shared URL that could be picked up from a location.href lookup? eg campaign tracking codes. These allow you to learn more about the source of the click that loaded the resource page (ie they are metadata on the link that detail how it was minted when it was shared. You could imagine two links on the same page to the same resource (eg one wrapping text, one wrapping an image) that differ ito campaign tracking metadata that can be picked up when the detsination page is loaded?).

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...)

Contribute to the discussion

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