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.

4 thoughts on “Our DVLE model?”

  1. Hello there,

    That’s a very clear architecture you’ve got there. I would say that it’s a reasonably straightforward model 2: Plug-ins to existing VLEs. It’s just that the plug-ins in this case are service provisioned interfaces, rather than dedicated extensions of the host platform. Main point is: the integration points to Moodle are designed to be platform specific and extend the functionality of it.

    From what you’ve described as the main goal – rich and consistent interface – that seems to fit very well. That’s the strength of model 2. It’s weakness – lack of portability – is not something you’ve mentioned as a requirement.

    By that logic, a Moodle block is the obvious choice. However, wrapping what you’ve got in a Wookie widget is probably not that much more work, and gives you access to a larger community who might use your widget too and help extend and maintain it. And it gives you future options.

    In any case, I’d definitely go for separate blocks/widgets: it gets rid of unnecessary dependencies (i.e. if service A fails, all the other widgets still load), it allows for very easy substitution and subtraction in case of a system change or to accommodate local concerns, and you get much more re-use by others (many Moodle as well as non-Moodle users will use one or two of the same services, but few will use the exact same set)

  2. Hi Guys

    Great post – and just the kind of contexualised thinking we were hoping the briefing paper and the programme would generate. I agree with Wilbert separate blocks/widgets seems the most logical way to go. Will be interested to hear how it develops.


Leave a Reply