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

Working with partners: Talis Aspire and Equella

A distinguishing feature of our distributed VLE is integration of a range of complementary learning technologies: Moodle, Equella, Talis Aspire, campusM, etc, based on:

  • web services; and
  • consistent naming of data within different systems.

In consultation with library colleagues we devised a workflow for including digitized materials (stored in Equella), in reading lists, held in Talis Aspire and publicised in Moodle.
Digitizated Materials Workflow
As part of new Unit (module) approval procedures introduced to support MMU’s EQAL curriculum transformation initiative, tutors are required to provide reading lists that distinguish items to buy, essential and further reading. Where essential or further reading can be delivered digitally, tutors are encouraged to use electronic sources and, within the terms of the institution’s Copyright License Agreement, tutors and library staff have been identifying chapters and articles for digitization. Library colleagues are agreeing a format for the “notes for librarians” field that will enable clear digitization instructions to be captured against item entries on Unit reading lists. All Talis Aspire lists are reviewed prior to publication. If digitization requests are encountered then the chapter or article will be scanned, uploaded to Equella, tagged with the Unit code and, finally, the Talis Aspire list item will be updated with the Equella URL. To make the outcome of this workflow as easy as possible for students, we wanted the Talis Aspire link presented in Moodle to be single-sign-on.

In an earlier post, we described a Talis Aspire integration scenario that went beyond the sample code provided for Talis Aspire. We wanted to supply a Unit (module) code and an academic year identifier and retrieve titles and URLs for the items on the reading list for that unit and display the content in Moodle. We prototyped a solution for this which initially parsed the RDF for the unit code to identify the URI for the relevant list and then parsed its XHTML representation. As prototyping began to move towards production deployment we started looking for performance improvements in our code.

On Tuesday, May 24, colleagues from Talis Aspire were on site for a project catch-up. We agreed a new naming convention for identifying versions of lists for particular academic years, provided data for a new Unit hiearchy that reflected this convention, and raised our two technical challenges with Chris and Ian:

  • providing single-sign-on links to Equella resources on Talis Aspire lists when those lists are displayed in Moodle
  • speeding up access to list item titles and URLs for a given Unit code and academic year

Chris demonstrated a new feature of Talis Aspire, which allowed javascript widgets to be added to Talis Aspire pages which could interact with the page’s content or extract data from its calling URL.

After 35 minutes of agile development, Chris had produced and deployed to our Talis Aspire tenancy a widget that could retrieve a single-sign-on token from the querystring of a list item page, and append this to the reading list item URL used to access material in Equella; Alex had modified the web service used to publish data in Moodle from Talis Aspire and Equella so that links to Talis Aspire items were appended with a short-lived token that would grant single-sign-on access to Equella.

Steve, Chris + Alex in agile dev mode

In just 35 minutes, powered by enthusiasm, coffee and a large tub of chocolate, we had achieved our aim of seamless access from Moodle via Talis Aspire to digitized journals and chapters stored in Equella!

Chris also mentioned that Talis Aspire supported CSV representations of lists, as well as the XHTML representations we had been parsing in our web service. We found the CSV representation gave a noticeable performance improvement of over 200ms per call, and have incorporated this change into the production codebase.

Our distributed VLE depends on integrating solutions from a number of different partners, and the kind of working relationship described in this post is a key enabler for delivering our DVLE vision.

Responses from 100 device-led student interviews

Between January and March 2011, one hundred students were interviewed about their use of technology and places of study at Manchester Metropolitan University (MMU). The interviews took place at locations across MMU and, as far as possible, students were selected in order to give a course and gender balance that reflected MMU as a whole. Students were asked to talk about the technology that they had with them. Those who took part were rewarded with a £5 print credit voucher.

Detailed analysis of the results and reflection on questions will follow, but this post presents preliminary analysis of headline results for students’ use of technology in their studies. Please note accuracy of data is yet to be validated by the research team, and use of specialist equipment, for instance Apple Mac computers available to Design students, is yet to be factored in. These results are presented as a preliminary indication only and should not be considered safe for citation.

A link to the interview schedule is available here.

Of the 100 students interviewed, 98 had brought a mobile phone with them and 45 had brought a laptop (or netbook). Questions concerned use of the devices *for* learning and study.

Frequency of Technologies Used In Learning 20110610

Used in learning Mobile Laptop Desktop
10+ times/day 15 4 0
6-9 times/day 2 4 0
3-5 times/day 13 13 2
1-2 times/day 17 6 7
5-6 times/wk 6 8 8
3-4 times/wk 14 6 10
1-2 times/wk 15 1 17
less than 1/wk 6 2 6
Total 88 44 50
Locations for Technology Use In Learning 20110610
Accessed from Mobile Laptop Desktop
uni 79 31 40
home 81 43 21
work 32 4 1
train/bus 67 13 n/a
café/pub 57 15 n/a
Technologies Used In Learning 20110610
Supporting learning with Mobile Laptop Desktop
calls 62 2 0
texts 76 0 0
e-mail 49 42 42
social networking 45 37 31
web 47 43 44
uni portal 31 43 40
uni VLE 25 42 38
e-books/journals 11 18 22
blogs 13 17 15
youTube 21 36 25
podcasts 9 17 9
music 11 14 7
films 2 20 7
TV 3 24 12
Apps 21 0 0
flickr 4 5 1
taking photos 28 2 1
taking video 10 1 0
games 5 1 0
dictionary 2 0 0

Initial Observations:

If the number of mobiles used for email and web is taken as an indicator of smartphone ownership amongst the students interviewed, then the figure of 49/98 (50%) is practically identical to the figure obtained in the online survey undertaken in October 2010 (496/982 = 50.5%).

Despite popular opinion that students use social networking rather than email for communication, more of those interviewed used email for learning-related communication:

Supporting learning with Mobile Laptop Desktop
e-mail 49 42 42
social networking 45 37 31

Interestingly, email use was more common on mobiles than on laptops or desktops.

Reflection on questions and responses in the online survey and interviews:

For future studies, it could be useful for research instruments to elicit responses for different (but sometimes overlapping) categories of technology-use for learning:

  1. Discussing and arranging course work
  2. Accessing course deadlines, timetables, briefs and feedback
  3. Discovering and accessing learning materials
  4. Producing and submitting course work
  5. Maintaining a personal study environment

An initial skim of the qualitative interview data suggests that mobile messaging, particularly texts and blackberry messenger (BBM), is used extensively for category#1.

Category#2 access to e-admin information to support learning emerged as the top priority for institutional mobile development in the larger (982 respondent) online survey

Prompts in this questionnaire could have done more to elicit responses about category#3 and category#4 use, but it is interesting to see in both the quantitative data and the qualitative responses to technology and study space questions that a number of students place an importance on playing music while studying (category#5).

As ever with W2C, we look forward to feedback and further ideas generated by this post.

Widget development

Over the last few months, W2C has been laying foundations for its extensible VLE by developing web services to publish frequently-asked-for information from university systems. We are now ready to test the potential of W3C Widgets as a mechanism for publishing the output of these web-services on a range of platforms, and have just written our first widget. This post describes our experience.

To de-scope security issues from our first development, we decided to develop a widget to publish public data available from our PC Availability web-service. First we reviewed published examples of widgets and found particularly helpful WIDE’s step-by-step guide to developing a Calendar web-service and Scott Wilson’s recent post on progressive enhancement of mobile content. Based on this initial review, we decided that our widget should use:

  • jQuery – javascript library (to consume our web-service)
  • jQuery-mobile – javascript library and CSS (to render the content)
  • A simple Controller model to organise our javascript functions

and we knew we’d need:

  • a Wookie server – Steve’s working on a post about lessons learned from getting this going!
  • a folder structure in which to develop our PC Availability widget, comprising
    • config.xml
    • pc.html
    • scripts folder, containing:
      • latest copy of jQuery.js (minimized version)
      • latest copy of jQuery-mobile.js (minimized version)
      • our javascript: pc.js
    • style folder, containing:
      • latest copy of jQuery-mobile.css (minimized version)
      • folder of jQuery-mobile images

Our files contained the following:

[codesyntax lang=”xml” title=”config.xml”]

<widget xmlns="http://www.w3.org/ns/widgets"
  <name>PC Availability</name>
  <description>A sample widget to display PC availability</description>
  <content src="pc.html"/>
  <author>Mark Stubbs</author>

Our config.xml file defines a simple “PC Availability” widget that will be loaded from pc.html. Default size has been set as 320×480 for mobile rendering.

[codesyntax lang=”xml” title=”pc.html”]

<html lang="en">
	<meta charset="utf-8" />
	<title>PC Availability</title>
	<link rel="stylesheet" href="scripts/jquery.mobile-1.0a3.min.css" type="text/css" />
	<script type="text/javascript" src="scripts/jquery-1.5.1.min.js"></script>
	<script type="text/javascript" src="scripts/jquery.mobile-1.0a3.min.js"></script>
	<script type="text/javascript" src="scripts/pc.js"></script>
  <body onLoad="Controller.init()">
    <div data-role="page" id="home">
      <div data-role="header">
        <h4>PC Availability</h4>
      <div data-role="content" class="ui-content">
        <ul data-role="listview" id="rooms-listview" data-theme="d" data-inset="true">
      </div><!-- /content -->
    </div><!-- /page -->

Our pc.html file loads the jQuery-mobile 1.03a stylesheet; the jQuery 1.5.1 minimized library; the jQuery-mobile 1.0a3 minimized library and our own pc.js javascript. The body tag contains an onLoad handler that calls a javascript function we have defined for the Controller class called init(). The xhtml within the page is organized to present information as a single page (using the div data-role=”page” tag), which has a header (div data-role=”header”) and content (div data-role=”content”) section. Within the header section, the h4 tag is used for the page title. Within the content section, an unordered list tag is included (with an id of “rooms-listview”), which will contain list items for current PC Availability at each drop-in space within the university. The ul tag is styled with some jQuery-mobile markup: data-role=”listview” data-theme=”d” and data-inset=”true”. Further information about controlling the presentation of list data in jQuery-mobile is available at http://jquerymobile.com/test/#docs/content/../api/../lists/lists-themes.html.


[codesyntax lang=”javascript” title=”pc.js”]

var Controller = {
	init:function() {

	update:function() {

		var loc = Widget.proxify("http://testapis.ad.mmu.ac.uk/icts/Service1.svc/getPcAvailability");

		        type: "GET",
			url: loc,
			dataType: "xml",
			timeout: 1000,
			complete: Controller.parseResponse

	parseResponse:function(response) {

		var rooms = $("#rooms-listview");
		$(response.responseXML).find("room").each(function () {
			rooms.append($("<li/>").text($(this).attr("location") + ": "
			+ $(this).attr("free") + "/"
			+ $(this).attr("seats") + " free"));


Our scripts/pc.js file defines the Controller class referenced in the body onLoad handler of pc.html. The Controller class has 3 functions:

  1. init()

    initializes by simply calling the update function

  2. update()

    uses Wookie’s Widget.proxify to get a URL within the same domain (using Wookie’s proxy to avoid cross-domain scripting restrictions) that can be used to call the PC Availability web-service, which it then does using the jQuery $.ajax function; this calls the Controller’s parseResponse function when it completes, passing across the httpResponse received from the web-service call.

  3. parseResponse(response)

    gets a handle for the rooms-listview element, clears its content and then iterates over the “room” elements in the xml returned from the web-service. A function is defined for handling each room element that is found. That function appends to the rooms-listview element a new list-item and sets the text of the list-item to be the location followed by the number of seats free, followed by the total. The parseResponse function completes by refreshing the rooms-listview with this new content.

On our Windows 7 development machine, we selected the pc.html, config.xml and the scripts and styles folders and right-clicked on the “send to Compressed (zipped) folder” option. We then renamed the resulting file “pc.wgt“. From the Wookie Adninistration menu we clicked the “Add new widget”, browsed for our pc.wgt file and clicked the “Publish” button to add it. Our PC Availability widget (minus an icon, as we hadn’t specified one in the config.xml file) was then available in the widget gallery for testing. We added the address of our PC Availability web service to the Wookie white list (so that the Widget.proxify command would work for the URL we’d specified) and then clicked on the demo button in the gallery, which produced this in Firefox:

Screen-shot of PC Availaibility widget running in Wookie using Firefox 3.6.15
Screen-shot of PC Availaibility widget running in Wookie using Firefox 3.6.15

We then tried in IE8 and the widget was rendered without any CSS and a javascript error. After much searching we found this post about IE support in jQuery, which suggests that work still needs to be done for IE 7/8 and Windows Phone 7, but that Scott Jehl had produced an “at your own risk” workaround that must be loaded after the jQuery library and before the jQuery-mobile library loads. We inserted the javascript inline between the two library calls, and the widget then rendered in IE8:

Screen-shot of PC Availability Widget rendered in Wookie using IE8.0.7600
Screen-shot of PC Availability Widget rendered in Wookie using IE8.0.7600

Apart from not having rounded corners, there was no obvious difference between the rendering of the two in different browsers (content differs as expected from a dynamic feed).

We then tried in a number of other browsers:

  • Safari on web and iPhone worked
  • the Android browser worked on a phone and a Galaxy Tab
  • the native browser failed to display anything on a Blackberry or a Windows Mobile 7 phone
  • Opera mobile worked on a Blackberry

Our initial foray into the world of widgets was pretty positive, although support for popular Windows browsers would need to move beyond an “at your own risk” hack for the interesting progressive enhancement approach to be viable for production deployment. We hope this post will encourage others to have a go and share their thoughts.

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

Developing web-services

MMU’s initiative to Enhance Quality and Assessment for Learning (http://www.blogs.mmu.ac.uk/eqal) includes a specific strand to raise “student satisfaction, engagement and success by providing a more seamless and personalised online experience of university activity” (http://www.blogs.mmu.ac.uk/eqal/C47/). This strand provides the project management framework for delivering MMU’s new VLE, extending its SharePoint Portal and developing mobile access to institutional systems. The W2C project will share our experience of adopting a service-oriented approach to the delivery and integration of these system enhancements.

The W2C development team are currently working on a number of REST web-services:

  • getWebCtAreas – to return a personalised RSS 2.0 feed of a user’s VLE areas, with single-sign-on links if called with a suitable security token
  • getWebCtAnnouncements – to return a personalised RSS 2.0 feed of announcements on a user’s VLE areas, with single-sign-on links if called with a suitable security token
  • getFeeStatus – to return a personalised set of “traffic light” indicators of payment status for a student’s tuition, accommodation and other fees if called with a suitable security token
  • getPcAvailability – to return a dynamic list of PC usage in the drop-in computer suites

The list will expand over the coming months, and will be the subject of further blog posts as we share our thoughts about security and data structures.

We expect these web-services to be consumed within:

  • our SharePoint Portal;
  • our new CampusM mobile application; and
  • the widgets we will be building within the W2C project.

We will share our experience of doing so via this blog.

Welcome to W2C: extending the VLE through Widgets, Web- and Cloud-services

MMU has recently (and publicly) reviewed its learning technologies and will be making significant investment in a new integrated VLE and Repository. The W2C project plans to enhance and extend this investment by opening up new development paths and will share with the sector the experience of pursuing them on an institutional scale.

The W2C project will demonstrate in particular the potential of Widgets, institutional Web-services and Cloud-sourced services for delivering an institutional vision of convenient, integrated and extensible learning systems.

MMU has recently (and publicly) reviewed its learning technologies and will be making significant investment in a new integrated VLE and Repository. The W2C project plans to enhance and extend this investment by opening up new development paths and will share with the sector the experience of pursuing them on an institutional scale.

The W2C project will demonstrate in particular the potential of Widgets, institutional Web-services and Cloud-sourced services for delivering an institutional vision of convenient, integrated and extensible learning systems.

It will do this by:

  • sharing as widely as possible our vision for learning systems, our scenarios and threshold user expectations that emphasise convenience, integration, personalisation and extensibility
  • sharing the business rationale for our recent decision to adopt a “core plus” model for our learning systems in which a core VLE and Repository is extended through widgets, web-services and cloud-sourced services
  • mapping the processes in which institutional data necessary for delivering key user requirements are created and maintained (using standards such as BPMN), suggesting change where necessary to maximise opportunities for interoperability and data re-use
  • developing, to open standards where possible, web-services for institutional systems that hold definitive data required to meet user requirements
  • developing or downloading open source widgets to consume our web-services
  • deploying the widgets and selected cloud-sourced services into our VLE
  • evaluating student and staff experience of using the widgets and cloud-sourced services in the VLE and on personal devices
  • evaluating teaching and administrative staff experience of working with usage data available from institutional systems and cloud-sourced services
  • summarising lessons learned from the widget/web-services/cloud-sourced services approach for delivering convenient, integrated, personalised and extensible learning systems
  • critiquing the value of the CETIS DLE model for explaining our approach and the e-Framework for guiding our web-services design
  • blogging project progress and encouraging feedback on our dynamic case study via blog comments and twitter (hashtag = #MMUW2C or follow @mmuw2c on Follow mmuw2c on Twitter)

We expect this activity to:

  • enhance the capability of our VLE to meet existing and emerging user requirements
  • enhance user satisfaction of our learning systems
  • heighten awareness about patterns of student engagement and success
  • facilitate discovery of learning resources that others have found useful
  • accelerate development of a community of practice for educational widgets
  • improve, by providing practice-informed feedback, key sources of information available to others in the sector contemplating similar endeavours.

The W2C project is funded by the JISC’s E-Learning Programme, under Strand B of the 03/10 Distributed Virtual Learning Environments call. It started on July 1, 2010 and will complete by December 2012. Further posts will provide more detailed information on timing of the deliverables listed above. Please check back regularly for details of project progress.