DOULS

It’s been a long (long) time since the last blog post about the project and there is a list of a whole lot of things that we have been working on to disseminate. So here goes with item number 1 – the study planner gadget.

As mentioned, back in May, in a blog post by our project director Niall Sclater (The Distributed Learning Environment Comes a Step Closer) we have produced a Google (OpenSocial) Gadget that displays a student’s Moodle course website(s) study planner(s). Since this initial version there have been a number of minor updates and improvements and now the gadget is in testing ready for release, the end of, next month. There were some useful lessons learned during the development and I’m going to try and document them in this post, along with an overview of how the gadget works.

The gadget comprises of:

1. Gadget XML
2. Moodle SNAPP plugin
3. Moodle web service to return planner info
4. Moodle web service to set activity completion status

The gadget is populated by HTML content returned by a web service in the OU ‘studyplan’ Moodle course format. The web service calculates which ‘live’ Moodle courses the user is enrolled on and returns information on these to the gadget, in JSON format. The web service calls the same code that is used to create the main course view content, so the HTML returned is exactly the same as that used when accessing the course page on the VLE. This means that the gadget will always reflect any changes made to the VLE, so there is no need to maintain it separately. The gadget loads in the CSS used in the OU’s Moodle theme and applies class definitions to the content container div that match those declared within the Moodle page so that the gadget content looks the same as the content within the VLE.
If the user is enrolled on more than one Moodle course each are displayed within tabs in the gadget. The tabs are generated using the YUI3 JavaScript library and use WAI-ARIA for accessibility. Gadgets support a native tab system but these did not seem to be that accessible in iGoogle (keyboard) and do not utilise ARIA.
The gadget can be ‘maximised’ which will switch it to use the ‘canvas’ view. When in this view the gadget is re-sized, using call gadgets.window.adjustHeight(), when each tab is selected to ensure that the scrolling of the gadget is correct.

Setting activity completion status (gadget to VLE communication)

As well as receiving information from the VLE the gadget also sends data to the Moodle instance. Within the gadget the student will see an indication of the completion status of an activity. As with the VLE they can manually set the completion status to complete/not complete from the gadget. This presented some challenges as the use of a web service to update completion status was not enough on its own.  This was due to the caching of completion information in Moodle within the user’s session; because of this changing the completion status via a web service means that the user will not instantly see the updated status if they are already logged in.
To overcome this issue the following steps are undertaken when completion status of an activity is changed by a gadget user:

1. A cross-domain ajax call (CORS) with credentials is made to a page in Moodle that sets the activity completion status (which does so by calling the usual page that sets completion via AJAX). This will only be successful if:
   1. The browser supports this call (later versions of Firefox & Chrome etc – not IE)
   2. The user is logged in to the VLE.
2. If the CORS call fails because the user is not logged in then a web service call is made to update the activity completion status.
3. If the CORS call fails for any other reason (or the browser does not support) then:
   1. a json-p call using YUI is made to the same Moodle page. The user will need to be logged in to the VLE in order for this to be successful
   2. As we cannot be sure of the success of the json-p call (there is no mechanism to detect failure), a web service call is also made to update the activity completion status.

Summary of some of the lessons learned during development

1. Error checking – have lots of it. When making AJAX calls and then doing something with the returned data the more error checking and graceful failure points the better.
2. Don’t trust that that osapi.get calls will always return an error correctly. With the signed requests through to Moodle initially there was only error checking against an error being returned. However, sometimes the authentication from iGoogle seems to go a bit wonky and will expire so all signed requests fail. These don’t return an error – instead I also had to check the status of the response to detect when things went wrong.
3. Debugging script in gadgets can be frustrating. Refreshing iGoogle presents the gadget from a new url, so debug breakpoints get lost.