Our DVLE model?

Sheila and Wilbert’s Distributed Learning Environments briefing paper describes 5 possible integration scenarios and invites consideration of their relative strengths and weaknesses. We have given some initial thought to where our W2C work would be positioned and it seems our emphasis on re-usable web-services is producing a hybrid that straddles the JISC-CETIS DVLE categories.

Our approach has aspects of Model 1 in that we have a collection of services gathered in one place, consumed from a range of platforms. However, for W2C the service collection is at the web-service rather than the widget/IMS tool level. We wish to use a subset of these services within our Moodle VLE to deliver our vision of convenient, integrated and extensible learning systems, and this potentially introduces aspects of Model 2 (see below).

Feeding the VLE

Previous focus group and survey evidence has made a strong case for consistency as a valued aspect of VLE interaction, and we are keen to use our collection of web-services to enhance the student experience in this regard. We are therefore pursuing a strategy of making our VLE an aggregation point for the consistent display of relevant data from a number of university systems. To realise this strategy we have argued for a university-wide tagging convention in which the code used to identify an offering of a Unit of Study in the Student Records System is used to tag material of relevance to that Unit. We have approved a university-wide Moodle policy that states that areas will be created to support every Unit of Study and will be identified by their Student Record System codes. As Moodle blocks can pick up the identifier of the current course and authenticated user we have all the information we need to make calls to our collection of web-services to transform Moodle courses into hubs for presenting a raft of consistent, personalised information, such as:

  • the authenticated user’s up-coming timetable for the Unit
  • the authenticated user’s assessment deadlines and any preliminary marks for the Unit
  • any podcasts tagged as relevant for the Unit
  • the reading list for the Unit
  • any chapters or articles digitised to support the Unit
  • any past papers for the Unit

We have written these features into our Moodle policy as threshold standards for a Unit of Study presence:

Moodle Unit of Study course area

We source the information from a number of corporate systems: Unit4 (formerly Agresso)’s QLS, Scientia, Apple Podcast Producer, Talis Aspire and Equella:

Aggregating tagged data from corporate systems into the Moodle Unit hub

We now face some architectural decisions about how best to deliver this information into Moodle:

  1. A single custom block that incorporates all the calls?
  2. Multiple custom blocks, one for each call?
  3. A single Widget that runs in the Wookie-Moodle block and incorporates all the calls?
  4. Multiple Widgets that run in Wookie-Moodle blocks, one for each call?

Our decisions will be influenced by usability and accessibility issues – for instance the ease with which the Block or Blocks inherit Moodle’s CSS and pick up any high-contrast, large-font variants. Performance and ease of maintenance will also be factors as this needs to be live for all MMU students (34,000+) from September 2011. Our decisions will be informed by some intense prototyping but we would really value thoughts from the community on the best way to go.

Reading List Web Services

MMU’s learning technologies review (2010) selected the Talis Aspire hosted reading list system to play a key role in delivering its vision of an integrated and extensible VLE.

Following the review, policy statements were drafted and approved that set out threshold standards for VLE content at Unit (Module) and Programme level. A policy was also developed to govern the structure and normal length of reading lists. Together these policies set out a requirement that each instance of a Unit of study should provide links to reading materials organised in terms of three categories: recommendations for purchase; essential reading available through the library; and further reading.

Colleagues at Talis have already described some integration scenarios between VLEs and Aspire (using JSON and RDF APIs), and have developed some sample code for Moodle that demonstrates the potential of Aspire APIs for blurring the boundaries between systems to create a more seamless user experience.

In order to meet our policy requirements we realised that we would need something more than the functionality provided by the sample code. Our requirement is to present all the Aspire reading list items within Moodle as clickable links organised in terms of the three categories from our reading list policy. It might not be a scenario that Talis originally anticipated, but our consistent tagging policy based on curriculum codes and their commitment to semantic web principles and open architectures offered a way to achieve this.

Each area created in Moodle to support an offering of a particular Unit of study is created with a course id formed from concatenating the Unit Code, with an underscore, the academic year of delivery, a second underscore, and the occurrence code within the year. For instance 2CP3D011_1011_3 refers to the March-starting instance of the Unit 2CP3D011 within the 2010/11 academic year.

In Aspire we have chosen to create Reading Lists for Units per academic year (rather than Unit instances per academic year), as reading list items are consistent for all offerings of a Unit within a given academic year. The Aspire Reading List for the Unit mentioned is thus created with the tag 2CP3D011_1011, which can be derived easily from the Moodle course id. The consistency of our coding convention gives us the basis for a standard block within Moodle for bringing in content from Aspire.

Aspire supports URLs that reference its tag hierarchy. For instance, http://lists.lib.mmu.ac.uk/units/2cp3d011_1011.html displays lists attached to the (lower case) 2CP3D011_1011 unit tag. The XHTML returned could be scraped to get the URL for the list, however it is easier to use the RDF version:
http://lists.lib.mmu.ac.uk/units/2cp3d011_1011.rdf

The RDF representation provides a detailed data set including a reference to the list being described:
<rdf:Description rdf:about=”http://lists.lib.mmu.ac.uk/lists/4CC5DCEC-B912-F9F9-163F-ED69F4F2B70A”>

The contents of the HTML representation of this list provide all the items to display in Moodle (including any category information indicating whether it is an item recommended for purchase etc):
http://lists.lib.mmu.ac.uk/lists/4CC5DCEC-B912-F9F9-163F-ED69F4F2B70A.html

To meet our policy requirements we prototyped a .NET web-service that used the RDF to identify the XHTML representation of a list for a given Unit tag and transformed the response to produce a RSS feed that can be called for a given Unit:
http://testapis.ad.mmu.ac.uk/collections/Service1.svc/lists/2CP3D011_1011
We are developing a Moodle block that picks up the course id and appends the appropriate parts to create the URL to feed a modified RSS reader that distinguishes our 3 categories of list item.

We are interested to know whether this light-weight RSS integration approach would be of interest to others as a VLE-Reading List integration scenario?

Device led student interviews

During January and February the Project Team (members of Learning Research & Information Services and the Centre for Research in Library & Information Management) will be carrying out 100 short impromptu interviews with MMU students. The aim of the research is to find out about students’ use of technology in their studies. A pilot has already been run and the team are currently tweaking some of the questions based on the responses and feedback received. What’s distinctive about the interviews is that the questions are device led i.e. asking students to show us the technology device/s they are carrying with them there and then (whether it be a notebook, Kindle, mobile phone etc) and ask how these devices are used in their learning (including what they use them for, where and how frequently). We’ll also be asking how well students feel MMU supports their use of technology and how it could be improved. By using this method it is anticipated we will gather some very meaningful research – to be utilised at the next stage of the W2C research… student design workshops (more info to follow!)