Welcome to LRT Sites. This is your first post. Edit or delete it, then start blogging!
As projects in the JISC’s Distributed VLE programme draw to a close, JISC-CETIS has been facilitating events to share lessons learned with the wider community. On Friday, January 13 (yes really!), we’ll be joining colleagues from the SLEP project in Southampton in a “virtual brownbag lunch session”. In readiness for the event we’ve put together some slides to structure our contribution:
The W2C project set out in July 2010 to demonstrate the potential of Widgets, Web-services and Cloud-sourced services for delivering an institutional vision of convenient, integrated and extensible learning systems. We hoped this work would:
- 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
After 18 months of intensive work it is important to assess our progress against these ambitious aims and to reflect on new directions and lessons that have emerged from the activity.
Target #1: to enhance the capability of our VLE to meet existing and emerging user requirements
MMU’s move to Moodle was shaped by extensive focus group work on students’ expectations of a good online learning environment. The importance of a one-stop-shop for administrative information came through as a critical hygiene factor (a requirement that has subsequently been reinforced by our research into students’ mobile needs). We consequently put a lot of effort into aggregating frequently-requested administrative information such as module timetables, assessment deadlines and reading lists, and devised a mechanism to publish a personalised, contextualised feed of this information in Moodle (see our mega-mashup post). This institution-wide innovation was launched on September 1, 2011 when Moodle became our institutional VLE. Hit data for the service powering the mega-mashup demonstrates that this service has quickly become a key part of institutional infrastructure!
- Between 01/09/11 to 11/12/11, our main web-services server has responded to 11,841,793 requests
- That’s an average of 116,096 hits a day
- or 4,837 per hour!
- Our getInfo (mega mashup) service accounts for 3,138,539 of those hits
- Our getTimetables service accounts for 2,556,593 of those hits
The graph below provides a breakdown of the most popular web service calls in the first 100 days.
Target #2: to enhance user satisfaction of our learning systems
For 5 years, MMU has been testing and refining an online system for gathering student satisfaction. Integrated with the student records system, the system asks each student a set of standard questions about their course and modules. In the 2010/11 academic year, the system was piloted in three faculties (Humanities, Law and Social Science; Business School and Science and Engineering). For 2011/12 it has been deployed university-wide. Questions have remained constant across the two years and two closed questions are of interest for assessing the extent to which Moodle is delivering frequently-requested administrative information:
- The course is well organised and running smoothly
- University resources are appropriate to my learning needs
Response rates on this year’s survey have been staggering. Over 10,000 students have submitted feedback and have provided over 56,000 comments.
For the pilot faculties we have data before and after the Moodle launch for these two questions and have been able to break down interim responses by year of course to test for any improvements.
Clearly our work with Moodle has been part of the much larger EQAL change initiative, so we cannot claim these improvements flow directly from the W2C work, but it is encouraging to see satisfaction levels rise in the two key areas we’ve focused on.
Target #3: to heighten awareness about patterns of student engagement and success
During the course of W2C, MMU launched a major project to transform its annual monitoring arrangements into a Continuous Monitoring and Improvement (CMI) system so our work around student engagement and success was directed towards supporting this. The CMI system will receive feeds from a number of sources, including Moodle tracking data and the online student satisfaction survey mentioned earlier. Consistent use of curriculum codes and person identifiers has been a critical part of W2C’s work for the Moodle deployment. It has enabled our mega-mashup, and will be playing a key role in joining data about engagement, satisfaction and success.
Since its launch in September 2011, Tutors have been using Moodle’s native last-login feature to raise awareness of students who haven’t been engaging with a particular module. However, programme leaders told us they were struggling to assemble a composite picture of their students’ engagement across all Moodle areas. We discussed the problem with our partners at ULCC and decided to commission a custom Engagement block that reports each student’s total hits for the last four weeks and allows the list to be filtered by groups set up in the course where the block is deployed. This would allow a programme leader to see engagement broken down by year of study (as our sync logic automatically enrols students on Moodle programme areas into groups for particular years of study).
The volume of activity on MMU’s moodle server (5 million in the first month, 6.5 million in the second) led to a number of iterations of the tool to establish a satisfactory response time, but we are now in the final stages of testing and lessons learned will doubtless be of use to ULCC’s other clients.
Target 4: to facilitate discovery of learning resources that others have found useful
As part of MMU’s “core+” VLE we have joined Moodle with EQUELLA and Talis Aspire and have been working closely with tutors to increase the number and structure of useful resources being signposted from Moodle. Resource lists are now mandatory when modules are approved, and MMU has approved a resource list policy that requires tutors to be clear about which items are recommended for purchase, which are essential and which are further reading. Take up of Aspire has been given a big boost as all first year modules were re-written for MMU’s EQAL initiative, and colleagues are now re-writing second and final year modules. To ensure that students’ experience of resources is as seamless as possible we have worked with colleagues at Talis Aspire to ensure single-sign-on access from Moodle via Aspire to resources stored in EQUELLA.
The next stage in our Talis Aspire project will be to exploit the potential of the shared service platform to explore recommendation services: eg, tutors like you also recommended this resource. We hope that our consistent use of curriculum codes will make it easy to add information, such as module JACS code and FHEQ level, to improve the accuracy of this recommendation service and we have already had some interesting dicussions with the Talis developers about this. As part of the wider Continuous Monitoring and Improvement (CIM) project we are looking to make resource usage data available to tutors when they plan their resource list for the coming academic year.
Target #5: to accelerate development of a community of practice for educational widgets
Although we have contributed to the widget development community and documented lessons learned, particularly about Wookie and our rapid development of a location-aware widget at the CETIS widget bash, our Distributed VLE model has prioritised cloud and web services for institution-wide deployment. We see this very much as laying the foundations for deployment via a variety of channels. Moodle, SharePoint and the CampusM mobile app have been our priority channels, but we may extend these channels to include widget deployment in future.
Target #6: to improve, by providing practice-informed feedback, key sources of information available to others in the sector contemplating similar endeavours
JISC funding for this work has provided us with the extra bit of space not only to innovate, but to share lessons learned. We have had great follow-up conversations about our institution-wide service-oriented “core+” VLE approach with colleagues from Bradford, City, Coventry, Nottingham, Oxford Brookes, Plymouth, Queen Mary University of London, Royal Holloway, Southampton, Staffs, University of the Arts London, Wolverhampton – and sincere apologies to anyone we’ve missed off the list! We really hope this blog and our presentations, such as recent ones to the Neil Stewart Associates Student Experience event and the UCISA Future is Mobile event, have been useful.
W2C has been an ambitious project, within an ambitious change programme. We have demonstrated that value can be added to a core Virtual Learning Environment through web services. By building strong strategic partnerships, we have been able to deliver a “core+” VLE through shared services for Moodle, EQELLA and TalisAspire and have blended this core with content from corporate systems. Through consistent tagging we have been able to aggregate relevant content around the user, and have proved that the service-oriented approach can work at institutional scale. We hope our Distributed VLE architecture and this account of its evolution will be of interest to others.
To support the communications strategy for our W2C project we agreed to present with our Moodle partner, ULCC, at UCISA’s Future is Mobile event. After my 6am start, you’ll see from the tweets I’ve repeated below that the day didn’t go exactly to plan!
I wasn’t too lucky with breakfast:
- And the prize for being up early for #UCISAmob … the dust + crumbs marking the end of the cereal #notmuchchewonatuesday
An unscientific device survey on the train revealed slightly surprising results:
- From my train seat the device scores on the doors are: iPhone=3 blackberry=2 windows=2
Then the trouble started: a train in front brought down the overhead power lines leaving a number of twitter colleagues wondering what time we might arrive in Birmingham:
- think @leoappleton ‘s train broke it @markpower is behind him. I’m behind Mark + @DMStephenson is behind me. It’s like an 11+ qu
- We’re gonna need a bigger boat yfrog.com/hwlcfdqj
We were eventually put on a coach heading back North, sharing data about mobile developments and hoping we might catch up with others
- The northern breakaway contingent of #UCISAmob (me + @markpower) is heading for Stoke: is the kettle on @FleurP ?
I arrived back in Manchester just in time to record a voice-over for the slides that I’d intended to present, which I uploaded to YouTube for my co-presenter:
- YouTube finally processed video for @fstoner at #UCISAmob http://youtu.be/X17yrTbdTHs really sorry I can’t be there in person!
With a stroke of genius for a “Future of Mobile” event, Frank then played the audio back via his iPhone to accompany the slides, which went down well with the audience!
- Wow…not only the future is mobile…the now is too…a mobile device is presenting #ucisamob
- Presenter didnt get to event due to issues, recorded sound file & sent 2 colleague, now playing back via an iPhone & mic #genius #UCISAmob
- A presentation by phone. THAT’S mobile. #ucisamob
- @thestubbs talking about researching mobile needs – via @fstoner ‘s iPhone 🙂 mobile technology at work at #UCISAmob !
- @thestubbs Listening to you speak on @fstoner ‘s iPhone at #ucisamob via live stream. #awesomenessindeed
- round of applause for @fstoner for toughing it out and holding his iPhone up to the microphone for so long #ucisamob
- @fstoner presenter stuck on a train? There’s an App for that! #UCISAmob
In the course of the day I’d used my mobile to:
- check the agenda, delegate list and location of the event
- listen to music
- get news about the train failure from the train operator and friends on other trains
- keep up remotely with the conference I’d been planning to attend (I narrowly missed the chance to vote while switching from train to coach)
- discuss and arrange how I was going to present remotely
And, of course, Frank used his mobile to present my voice from YouTube!
On reflection, these are pretty similar to the categories we’d asked student to use to categorise their use of mobile to support their studies:
- Checking deadlines/timetables: 66%
- Discussing/arranging work: 66%
- Listening to music/blocking noise: 38%
- Accessing learning materials: 35%
- Looking up references: 28%
- Taking notes: 28%
- Producing coursework: 8%
- Voting/interacting in class: 7%
- Commenting on learning: 6%
And, as I write this, the W2C blog and the video made in lieu of my presence are still being retweeted – and to think earlier in the day I’d been using the hashtag #UCISAstationary instead of #UCISAmob !
Between October and December 2010, W2C ran an online survey via the MMU student portal asking students to help the university shape its mobile development priorities by answering questions about devices owned, usage of those devices and priorities for mobile content. High level summary stats from that survey were published as an RSS feed on the right hand side of this blog and survey data informed our interpretation of 100 device-led interviews we carried out through W2C.
Recently, to support some equal opportunities work, we were able to match survey responses against age range and gender categories to give us greater insight into variety in need across our diverse student community. Our sample is inevitably biased towards users of technology as it required students to follow a link from the student portal, however for a subset of our sample (964 of 982) we have been able to see how device ownership varies with gender and broad age ranges.
|N||% of sample||Android||Blackberry||iPhone||iPod Touch|
Interpretation of this data must be done with caution. The sampling strategy meant that respondents were not representative of the institution as a whole. Addition of percentages implied by the graph is misleading as 164 students had an iPod Touch and a smartphone. Nonetheless, the graph draws attention to some interesting phenomena:
- Blackberry was particularly popular with females under 20
- iPhone was particularly popular with males over 40
- Android was a lot more popular amongst 20-40 year males than females
We hope to repeat this kind of analysis with subsequent surveys as it provides a useful reminder of diversity in device ownership and hints at the importance of cost and social norms in device ownership decisions.
Soon after the launch of the web timetables we were asked by the timetabling project team to investigate the possibility of a self-service feature for staff to produce class lists on demand, as central production and distribution of these was a potential bottleneck.
Scientia colleagues directed us towards an SWS report that produced class lists for activities:
Unfortunately the report presented its data as a series of tables with students sorted by surname in each. This gave us two problems to solve:
- How to give staff a usable interface for generating class lists for activities
- How to order data returned from the report so that it provided a useful class list
Giving staff an interface for selecting class lists
We had already developed a page that would proxy the SWS programmeOfStudy report to produce either a list or grid view of the timetable for any course. This page included a reference to every activity that had been scheduled, which could be passed to the SWS activity report. However, the timetabling team explained that not all of these would have class lists and we knew staff would be disappointed if some links appeared broken. After discussing the problem with Scientia, their consultants produced a custom programmeOfStudy report template that listed all activities for a course with the number of students allocated to each activity. We knew that every activity with a student allocation greater than zero would have a class list, so we had the data necessary to limit link creation to only those that would return a class list. However, the data needed to be scraped from HTML tables.
We decided that our proxy page would need to make two HTTP GET requests: the first would get the course timetable and inject CSS and some form objects (for varying display range and format); the second would get the activity list for the class and process the HTML to produce an array of activities with class lists. Before displaying the (re-formatted) output from the first course timetable request we could then iterate over the array of activities with class lists replacing the activity name in the HTML with a link to the class list page for that activity. When displayed on the screen staff would then have a class list with clickable links for every activity for which a class list was available.
We encountered problems loading the activity list report as XHTML, so we had to load as a string, extract the text between the body tags and remove some invalid characters and elements before we could process it as XML. However, once loaded, we were able to pick out all the activities that had class lists using XPath as the activity references were in the first column of rows without a @class attribute in tables of @class ‘spreadsheet’ which had a non-zero value in the 8th column!
//table[@class=’spreadsheet’]/tr[not(string(@class)) and not(td=’0′)]/td
The page to which we directed staff then had to solve the second problem of displaying useful class lists.
Providing useful class lists
After considerable experimentation, we found we needed to load the class list report as a string and extract certain parts as XML so that we could apply an XSL Transform to sort the students by surname and produce a report that staff would find useful. We decided to load only the parent table as XML, but before loading we removed invalid characters and blank rows. We were then able to apply an XSL Transform to produce the XHTML class list report sorted by surname (which appeared immediately after a space in the first column of rows that didn’t have a @class attribute):
<xsl:sort select="substring-after(td,' ')"/>
The final part of the solution was to provide staff with a list of course years for which class lists would be available. As class lists are only available where students have personal timetables, we asked for the student’s course code and name to be added to the view that indicated whether a student had a personal timetable. A SELECT DISTINCT on courses where there were students with individual timetables gave us the list we needed, which we included as an RSS feed to a staff-only page on timetabling’s intranet site.
As regular readers will be aware, MMU’s move to Moodle is part of a larger initiative designed to make a step change improvement in the student experience. The initiative, known as EQAL – Enhancing the Quality of Assessment for Learning, coordinates work on curriculum rules, quality processes, learning systems and admin systems, and includes introduction of new institution-wide systems for coursework submission (using a custom development) and timetabling (using Scientia). The need for easy-to-access, up-to-date, definitive timetable information has been a recurrent request in focus group and survey work, and featured strongly in our survey of students’ mobile information needs. This post describes how we used a service-oriented approach to give students access to timetable information.
We had originally planned to use Scientia’s Enterprise Reporting Database component to make timetable information available in Moodle and via students’ mobiles, but in late summer we learned that this could not be deployed for the start of term, so an intense period of re-thinking began.
Scientia includes a web publishing feature, known as SWS – Scientia Web Services, which produces HTML reports of student and course timetables specified via querystring parameters. Whilst incredibly fast, output from SWS lacks semantic mark-up, and makes extensive use of tables to control screen layout. We realised that this would impose limitations on what we could achieve, but we also became aware of two further complications:
- The scale and complexity of scheduling the entire MMU timetable meant that for performance reasons the scheduling problem was split into three geographically-distinct timetables: Crewe, Didbsury/Gaskell and all other Manchester campuses
- Each separate timetable had an SWS report server that ran on a non-standard port that wasn’t available over our guest wireless network (which we expected a lot of students to use)
We therefore needed to find a method of publishing web timetables that would work over wifi and on and off campus, and would hide from our students the unfortunate complexities created by having 3 separate timetable systems.
We were also aware that some but not all students would have personal timetables, and the set of students with personal timetables would change as they were allocated to particular seminars and taught groups. The aim of the EQAL project for September 2011 was to ensure that all level 3 and 4 students received personal timetables. However, some parts of the institution had committed to supplying the data necessary to give students on levels 5 and 6 personal timetables too. Our web timetable architecture therefore needed to ensure that every student saw either a personal timetable (if one were available) or their course timetable, and that this information stayed up to date.
We worked closely with colleagues on the timetabling project and with Scientia consultants to develop an architecture that ensured each student could access the best available timetable for them. A lookup table was created that indicated for any given student ID their campus (so we knew which SWS server to generate a report from), their course, and whether they had an individual timetable. Queries of this lookup table were wrapped as a simple RSS web service that returned for any given user ID, a customised URL for displaying their web timetable.
The customised URL included the port number of the SWS server that held the student’s timetable and specified whether the course or personal timetable report should be produced. The page then acted as a port 80 proxy to the SWS server so that the output could be displayed off campus or over wifi. The page also injected some CSS and some form elements to improve readability and make it easy to change the date and day range displayed.
Our architecture for displaying web timetables is shown below:
We added a custom WebPart to our myMMU SharePoint portal that called the timetable RSS web service for the authenticated user and set the href property of the timetable icon to take the student to the appropriate personal or course timetable for them.
In a previous post we described the background and rationale for creating a mega mashup web service that would aggregate relevant information at unit or programme level for the authenticated user and present it in a custom Moodle block.
For reasons of synergy with the skills of our developers, we chose to develop the mega mashup as a Microsoft Windows Communication Foundation (WCF) web service. WCF allows a service contract to be specified in which a template is provided for the web-service call and a class is specified for the data returned. We developed two main web services: one returning System.ServiceModel.Syndication.Atom10FeedFormatter output and the other returning System.IO.Stream output. The latter is produced by a function that applies a stylesheet transform to the output of the function that produces the former. The template for the two web-service calls is specified as returning WebMessageFormat.Xml for a UriTemplate of
user = authenticated moodle user
courseid = moodle course id
area = moodle course short code (in most cases will be a Unit or Programme identifier)
userRole = role of the current authenticated moodle user
userMailDomain = mail domain from the profile of the authenticated moodle user
format = determines whether Atom or an XHTML fragment is returned
developer = identifier to track the originator of calls to the web service
dtm = date-time stamp
token = security token
Our web service uses these parameters to form useful URLs for and retrieve data from a number of systems, grouping the responses using the source property of the Atom item into the following categories:
- Moodle News – Link to Moodle Announcements for the course
- Moodle Events – Link to Moodle Calendar for the course
- Live Mail – SSO link to Live@Edu for students with an @stu.mmu.ac.uk email domain
- Guidance – SSO link to coursework receipting system guidance
- Hand-ins – Feed from and SSO links to coursework receipting system
- Moodle Assessments – Link to Moodle assessments for the course
- Guidance – SSO link to coursework receipting system guidance
- To Buy – Items tagged as ‘to buy’ on the associated TalisAspire reading list
- Essential – Items tagged as ‘essential’ on the associated TalisAspire reading list
- Further – Items tagged as ‘further’ on the associated TalisAspire reading list
- Podcasts – RSS feed of a search of podcasts tagged with the course code on Podcast Producer server
- Files – SSO links to items returned in a search of EQUELLA for files tagged with course code
- Exam Papers – SSO links to past exam papers returned in a search of EQUELLA for files tagged with course code
- Timetable – Link to Scientia timetable that can be displayed for the current user
Classifying the source of each item in the Atom feed with a value from one of these categories allows the items to be grouped in the transform to XHTML, eg:
Coursework (<xsl:value-of select="count(//atom:entry[contains(atom:source/atom:title,'Hand-ins')])"/>)
<xsl:for-each select="//atom:entry[contains(atom:source/atom:title,'Hand-ins')]" >
<xsl:sort select="atom:updated" order="ascending"/>
<xsl:call-template name="showAtomEntryForAssignment" />
Our custom Moodle block then displays the XHTML fragment returned by the mega-mashup web service:
Over the summer, in the build up to going live with 40,000 users, we embarked on a comprehensive testing regime, stress-testing the web service using concurrency simulations from http://loadimpact.com/. We found our web services performed better on Windows 2003 than Windows 2008, so built our farm using Windows 2003. We also discovered that our Apple podcast server introduced unacceptable latency under extreme loads, so we chose to remove this from the mega mashup web service, as this is called on every visit to a Moodle course page, and decided instead to offer podcasts in a custom block for those Moodle areas that needed it. To speed up editing of Moodle pages, we also decided to disable calls to the mega mashup web service when the page was in Edit Mode, and instead just show a place-holder for the mashed-up content.
As load started to pick up for real in the weeks before the start of term we found that the mega mashup web service was backing up waiting for the Moodle web services to return detailed information about Moodle news, events and assignments. We therefore decided to remove the calls to the Moodle web services from the mega mashup web service, and just return links to the relevant Moodle pages for the current course id. This improved performance, but we still found performance problems under extreme load. We traced the problem to a wait cycle in which the server running the web services that provided users with single-sign-on from SharePoint into Moodle was backing up. As this server was also running the web services for the right hand block, Moodle was waiting to render pages, which meant resources weren’t being freed to service the single-sign-on requests. The wait cycle built up until performance ground to a halt. Once the cause had been identified, the single-sign-on and right-hand-block web services were moved onto different servers, the vicious wait cycle was broken, and performance returned to normal.
Now, even though it is aggregating latest data from Talis Aspire, EQUELLA and our coursework submission server on every view of a Moodle course page, our mega mashup web service is meeting performance targets and providing the information our staff and students have been asking for. We are extremely grateful to our partners at ULCC for helping us to deliver our vision of an integrated Core+ VLE, particularly as we have just heard that our Moodle server has been accessed by 35,588 distinct users who have performed over 5 million activities so far, with a peak concurrency of 1,477 users in a 5 minute period – not bad considering WebCT Vista was only switched off as MMU’s institutional VLE on August 31!
We entered our hosting agreement for Moodle in late summer 2010 and initially asked our hosting partner, ULCC, for a neutral 1.9 theme as our intention was to give the Moodle user interface a more substantial re-working in the run-up to going live for the 2011/12 academic year.
magneticNorth have an impressive track record of producing creative and engaging designs such as the BBC’s Desert Island Discs and Doctor Who video explorer websites. Our design brief to them was deceptively simple: to produce an attractive, clean and easy-to-use design for Moodle that had a family resemblance to MMU’s website. Oh, and it had to work with courses that were already active and be sufficiently familiar not to undermine the confidence of the hundreds of academic colleagues who had already been trained on our original theme. And it had to be done with Moodle 1.9, as we’d decided to play it safe and wait until others had flushed the bugs our of Moodle 2. And it had to be demonstrated to the Vice-Chancellor and Directorate on July 4!
magneticNorth designers worked through the design process with a small steering group from MMU and expert input from ULCC, gradually turning wireframes into functional and then technical specifications and then into a Moodle theme through consultation, prototyping and review.
Working within the constraints of Moodle 1.9 and in an effort to promote familiarity for our established users, we opted for a 3-column course page design that grouped navigation on the left, weekly content in the middle and aggregated information on the right. In parallel to the design and branding exercise, prototyping continued on the “magic block” for presenting users with the output of our Moodle mega-mashup, and markup for targeting CSS for this aggregated content was agreed.
magneticNorth’s proposal for a simple, fixed-width design that incorporated MMU’s house font of SerifaShopBold was accepted by the steering group and senior colleagues:
With these screen design signed off, work could then begin on the CSS, images and theme modifications necessary to deliver this look as a custom Moodle 1.9 theme. MMU purchased the SerifaShopBold web font and ULCC provided a copy of our existing Moodle courses in a test environment that enabled the new theme to be deployed and reviewed.
Work progressed extremely quickly and magneticNorth soon had a theme on the ULCC test server for review on a range of devices owned or borrowed by MMU’s Learning and Research Technologies team, the Centre for Learning and Teaching and faculty E-Learning Support Officers.
On July 4, the design was well received by the Vice-Chancellor and Directorate colleagues and go-ahead was given for deploying to the production Moodle when final acceptance tests had been passed.
The new design went live at the Moodle User Community meeting on July 13 and was marked with cake covered with an edible screen shot!
Having done such extensive testing we were surprised when colleagues reported that middle column content failed to display in edit mode in Internet Explorer on the production server. A detailed comparison of the theme files on the test and production sites revealed them to be identical and much head-scratching ensued. We eventually realised that MMU’s standard browser was configured to use compatibility view for intranet sites and to auto-detect intranet sites, which meant that IE browsed all *.mmu.ac.uk websites in compatibility view. We hadn’t picked this up in testing as we’d be browsing a site on the *.ulcc.ac.uk domain. Fixes have now been deployed and moodle.mmu.ac.uk is now proudly wearing its new design – big thanks to our partners at magneticNorth and ULCC and to our Moodle testers across MMU who’ve worked so hard to make this design a success.
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:
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|
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