Our Moodle mega mashup: part 1

In our learning technologies review we developed a vision of a core VLE integrated with our corporate systems, ideally available to students to use with the devices and services of their choosing, and extended through tools that the institution arranges, recommends or recognises. Following extensive options appraisal we decided that our core VLE would comprise Moodle, Equella and Talis Aspire, and developed our “core plus” model to manage expectations about funding and support for learnng technologies within MMU:

Core Plus VLE Model

This post focuses in particular on how we deliver our core VLE and integrate it with corporate systems. First we set out threshold standards for information that should be available within the VLE, then we describe our web service architecture for delivering that information.

Threshold standards for Core VLE information

Our learning technologies review was informed by focus groups and survey work undertaken during three year action-research fieldwork for a PhD. Findings from focus groups and surveys with students presented clear requirements for definitive administrative information – calls that have been echoed in W2C’s recent mobile survey. In Summer 2010, as part of a broader initiative on establishing threshold standards for the student learning experience at MMU, it was agreed that areas should be created in Moodle for every Unit (module) and Programme a student studies and every Unit should normally display:

  • Unit Title, Code and Teaching Team
  • Recent Unit news and events
  • Assignment Hand-in Deadlines
  • Reading List (ideally organized in terms of items to buy, essential and further reading)
  • Links to online learning materials: digitized chapters, podcasts, etc
  • Personal Unit Timetable for the user for the next month
  • A week-by-week teaching schedule

Gathering threshold VLE information

We decided that we could bring this information together with:

  • a consistent tagging convention, based on Unit and Programme codes from the student records system; and
  • a web services mashup

Within MMU, Units on which students enrol are identified using a combination of three identifiers:

  • Unit Specification Code
  • Academic Year
  • Unit Occurrence Code

All users, whether staff or students, are enrolled within Moodle using their unique Active Directory identifier.

Combinations of these four identifiers give us search terms for querying MMU’s corporate systems to gather our threshold standard Unit information.

Threshold From User ID Unit Spec Acad Year Unit Occ Note
Unit Title and Code Student Records X X X Cached in VLE
Teaching Team Student Records Extension X X X Synched to VLE
News + Events VLE X X X X
Assignment Hand-ins Coursework Receipting System X X X X
Reading List Talis Aspire X X
Learning Materials Files uploaded to Moodle X X X X Useful to flag recently added
Learning Materials Equella Learning Resources Collection X X
Learning Materials Equella CLA Collection X X
Learning Materials Equella Exam Papers Collection X
Learning Materials Apple Episode Producer Podcasts X X
Personal Timetable Scientia X X X X

Publishing threshold standard information

Through focus groups with staff we devised principles for a standard three column layout for every Moodle area:

  • Left = Navigation
  • Centre = Title, teaching team contacts + weekly content or topics
  • Right = Remaining threshold information

In consultation with our hosting partner, ULCC, we decided that Title and Teaching Team contacts could best be delivered by customization of the Moodle 1.9 course/view.php page, so we contracted ULCC developers to make the necessary changes to our Moodle site. For the remaining threshold information for display in the right hand column we decided, after some deliberation about widgets, that a custom Moodle block, which presented the output from a web-service, would be our preferred solution. We decided on a custom Moodle block, rather than a widget within a block, for the simplicity of entirely server-side presentation of content, avoiding IFRAMES, and the ease of applying UI preferences (such as font size increases) to all content on the page.

To power our custom Moodle block, we designed a mega mashup web service that could return either an ATOM feed or the ATOM feed styled with an XSL Transform to produce a valid XHTML page (for testing) or a valid XHTML fragment for display within the Moodle block. We chose ATOM, rather than RSS, as our syndication feed format for the increased sophistication offered on the SOURCE for each syndication item. We decided that we would use the SOURCE element to categorise items for display, and intend (eventually) to have valid SOURCE URLs to allow fragments of the feed to be accessed, rather than consuming the aggregated feed in its entirety.

We will describe the mega-mashup web service in more detail in a follow-up post

One thought on “Our Moodle mega mashup: part 1”

Leave a Reply