This gadget was the most ambitious produced and from the outset it was clear that the required functionality could not be produced entirely within a gadget and that a back end system would be required to provide core features.

The gadget consists of two core elements:

1. The gadget code and assets
2. The Buddy website.

The gadget provides students with some of the core functionality of the Buddy website from within their iGoogle page. Key features of the gadget are:

• Send a new message to a buddy
• View unread messages
• Alerts to invitations that need responding to
• View all messages
• View buddies
• View your profile
• View a buddy’s profile.

The website provides the same functionality as the gadget but also allows for:

• Managing buddies
• Managing messages
• Updating profile
• Finding a buddy.

In general terms functions that update or delete data are accessed from the website as this provides an extra level of security over the gadget.

The website has been developed using SilverStripe; SilverStripe is an open source PHP framework and content management system. The functionality required by the buddy system has been added to SilverStripe using its plugin architecture. Developments for the buddy system include:

• Buddy module – provides profile, buddy managing and searching for buddy
• Buddy messaging module – provides one-to-one messaging with a buddy
• SNAPP module – allows connection from Gadgets to SilverStripe web services.

SilverStripe was chosen for the development platform for the system as it provides a lot of features in its core that would have been cost prohibitive to develop from scratch. SilverStripe also has a strong developer community that have produced a number of plugin modules that are used in the buddy system.

Buddy module

The buddy module provides the system with all of the functionality around finding and managing buddy relationships with other users.

To be found as a buddy a student must fill in their profile; this contains a number of fields that identify their study interests and in what areas they can provide assistance to others. Their profile also sets up the user avatar and contains a number of system preferences relating to privacy.

Buddy profile editing

To search for a buddy the student fills in a form indentifying the key attributes they are looking for in a buddy. These would be their study interests and whether they are seeking help in a particular area. On searching the system matches these criteria against the students in the system and returns a list of matches.

Once the student has found a list of other users that match their criteria they can then select invite them to be a buddy by sending them an invitation. If the invitation is accepted then the two students become buddies and can message each other.

Buddy search options

The buddy module also provides the students with the ability to manage their list of buddies.

Buddy management screen

Buddy messaging

The buddy messaging module is a customisation of the open source Postale messaging system for SilverStripe. The messaging system allows students to communicate with a buddy in a one-to-one conversation. Because all communication is handled by the buddy system the contact details of the students are never revealed.

Messages from student's buddy

The Postal module was updated so that students can only message users that are in their buddy list. SilverStripe does have extensive extension capabilities that make it simple to override and customise php classes. Unfortunately, the level of change required to the Postale module was too great to practically use these methods so direct customisation to the code was undertaken. To manage future maintenance these changes have been implemented as a forked branch of the original github project. This should make the merging of any updates from the original code to our customised version straight-forward.

Message conversation thread

Gadget connection

The SNAPP module enables gadgets to connect to SilverStripe systems. This module code re-uses some of the libraries developed for DOULS for the Moodle gadget connection plugin. This module enables gadgets to connect to SilverStripe web services provided by the open source web services module. The SNAPP module extends this feature, providing custom authentication based on OAuth signing of the request by the gadget.

Buddy gadget

The buddy Google gadget uses JavaScript (YUI3 library) and OpenSocial API http methods (AJAX is also support on development/test environments) to interact with the buddy website web services and display the student’s buddy data.

The gadget is sectioned into a number of tabs – these are created using the YUI3 library.

Screen shots of each of the buddy gadget tabs

Design for the gadget was created by Paul Hillery, whilst the buddy website was styled using OU-ICE – a standardised branded CSS layout for OU websites.

Lessons learned

Firstly, this development was extremely ambitious in scope. Initial coding is now complete but there is a need for a small amount of further development, especially around guidance and support.

It certainly wouldn’t have been possible to produce the level of functionality delivered without the power and flexibility of both the SilverStripe framework and, within the gadget, the YUI3 library. The use of some open source developments to aid in delivering functionality also dramatically reduced development time.

Source code for the gadget and for the SilverStripe modules used to deliver the buddy website is available from the DOULS github area.

OU Open forum search gadget

The gadget integrates with two key OU sites:

1. OpenLearn –open educational resources
2. Platform – OU community.

Within the gadget the user can enter search terms and then has the option to chose which resources will be searched:

1. OpenLearn Learning Space Forum
2. Platform Forums
3. All of OpenLearn and Platform.

The main technical challenge for this gadget was the need to connect to different sites and access search information that is returned in a number of formats. Each of the three search options uses the same approach to request the search data (OpenSocial API http methods) but interpret the search results differently depending on the type of data returned. All three search types are fully accessed and controlled from within the gadget using JavaScript – there is no server-side code associated with the gadget.

Searching Learning Space forum

The Learning Space forum is hosted on a Moodle site and uses the OU ForumNG module to provide the forum functionality. Searching a single forum is straight-forward as there is a specific search page that expects parameters of the forum id and search terms in order to return appropriate results. The gadget requests this page expecting text (html) back as a response. The request is cached for an hour to prevent excessive load on the requested site.

In order to display the search results from the HTML returned by the forum search the page is “screen-scraped” by the gadget. The search page returned is cleaned and added into the gadget DOM into a hidden “buffer” element. From this certain nodes containing the search results are lifted, re-formatted and then inserted into the gadget search results area.

Searching Platform

Platform is the OU community site and is hosted on a Drupal site. Platform forums are searched using AJAX to return JSON results. The gadget mirrors this functionality, caching the request for an hour to prevent excessive load on the requested site. There are two types of forum that can be searched, the gadget uses a batch method to simultaneously request results from both of these.

As results are returned in JSON data format it is fairly straight-forward to interpret this and use to display the results within the gadget results area.

Currently the Platform search only returns matches based on forum titles, not content. Ideally, if possible, if the search returned matches against content this would be more accurate and mirror the functionality of the Learning Space search.

Searching multiple site content

Searching multiple sites and returning a result set provided a challenge as these results need to be amalgamated and “ranked” according to relevance to the search terms. This would be extremely complex to develop; so the gadget utilises a custom Google search for this search option.

The custom search is configured to search across several public facing OU sites:

• http://www.open.edu/openlearn/
• http://openlearn.open.ac.uk
• http://www8.open.ac.uk/platform/

The advantages of using Google custom search to provide this search option are:

• It can be configured to include extra sites as required
• Uses standard Google search technology to index and search sites, and rank results
• Free
• Provides analytics
• Provides an API.

The gadget uses the API provided by Google to request search results. This returns data in JSON format. Within the request the detail returned can be configured so that only the minimal data is returned to improve performance.

Unfortunately, the API will only process 100 requests per day under the no-fee model. To work around this limitation the gadget will detect when the daily limit is exceeded (as this information is returned with the API response) and in this case a fallback of presenting a link to a Google search page is used.

The functionality of this gadget differs quite significantly from the original requirements that were suggested from the visioning stage. Originally, the intention had been to produce a gadget that had a list of known open forum resources that a student could discover through recommendation based on a tag cloud; students would also be able to recommend resources to be added with a specified tag – these would then be “certified” before inclusion. Unfortunately, it was not possible to realise this original vision as there would be significant development required to produce this functionality. Also, institutionally there would be an overhead to maintain this list of “certified” forums i.e. if a Facebook group were recommended this would need to be checked periodically to ensure all material within it were appropriate.

The search open forum gadget is technically simpler and could be easily updated to include more resource sites at a later date. In addition, by searching OU sites that are already moderated there is no need to explicitly check content.

Grab of the collaborative status gadget

Connecting to the Moodle 2 VLE via the “SNAPP” plugin (developed for the DOULS project) the gadget receives information detailing:

• Active courses the user is currently enrolled on
• Collaborative activities available to the user on each course – these are ForumNG, OUBlog or OUWiki Moodle modules
• If there is any unread content on each of the activities.

This information is exposed via a Moodle web service that is installed in the gadget directory (gadgets local plugin). The SNAPP plugin enables secure communication (via the OpenSocial OAuth signing gadget feature) between the gadget and this web service.

The web service interrogates the system to highlight unread activity content via two methods. For ForumNG activities there is functionality within the module code that exposes if a user has yet to read posts. For all other modules the web service checks the last updated date of the activity against user visits in the Moodle log. In this instance obtaining an accurate reflection of whether the user has visited the activity is dependent on the data available in the log; at the OU log data is kept for approximately 2 months.

Development of this gadget was incredibly quick (1 day initial build) and straight-forward; demonstrating the flexibility of using the combination of Gadget technologies alongside our SNAPP plugin libraries and Moodle web services. Because of this the final gadget functionality closely mirrors the initial requirement that was collated from the visioning stage of the project.

The source code for the gadget (and SNAPP plugin) is available on the DOULS project github area.

ForumNG, OUWiki and OUBlog are Moodle activity modules created and maintained by The Open University. They are publically available in the Moodle plugins repository and also on the Open University’s Moodle developments github area.

In the second mode module teams are able to configure the tool to deliver forms to students via the Moodle interface. Student data entered within those forms can be saved to the students Google Docs account or as a .RTF.

Using this activity has a number of advantages over a tutor/teacher manually sharing a document directly with the cohort:

1. The document is shared from a central account and all sharing is handled by Moodle. It isn’t then an issue if the tutor becomes unavailable to manage the document.
2. A read-only document is shown to users who do not have access to Google docs.

Google collaborative activity

This activity requires an account in a Google Apps domain with OAuth API access enabled. Documents are created by the activity in this account and then are shared with the Moodle cohort. The document is shared with each user on access to the activity, sharing can be configured to use either the username @ google domain name or the email address associated with the Moodle user.

At The Open University we are using this activity in conjunction with a replication of course groups within our Google Apps domain. The activity shares the document with the correct Google group of users rather than the individual user; these groups are updated daily automatically using the Google Apps provisioning API (this is managed externally to our Moodle installation). This functionality could be replicated in other institutions with a small amount of code customisation in the module.
Our Google Apps domain also uses a single-sign-on mechanism – so VLE users can directly access Google docs without needing to sign-in independently.

Users who do not have Google Apps account or are not able to access the Google doc (but should still be able to see it e.g. administrators) will see a read-only version of the document. This is either an html file (doc/spreadsheet) or pdf (presentation) that is downloaded using the Google Docs API cached within the VLE, and then displayed in an iframe.

Google collaborative activity - read only document

The module supports the standard Moodle group activity model:

• No group – All enrolled users access a single document.
• Separate groups – A document for each group available, users can only access documents for the group(s) they belong to.
• Visible groups – A document for each group available, users can access all documents but will see a read-only version for any group they are not a member of.

The activity provides a number of features for administrative users:

• Template documents – An initial template document (doc/spreadsheet/presentation) can be uploaded to be used as the contents of the Google document when created. This can be one template for all groups or a separate document for a specified group.
• Document reset – documents in the activity can be ‘reset’ – clearing all content and reverting to template/blank.
• Sharing control – The sharing list for each Google document can be accessed from the administrative interface in the VLE and modified.

Google collaborative activity - document administration

Technical challenges

Connecting to a Google Apps domain and interacting with another user account requires authentication using (2-legged) OAuth; for this activity an open source OAuth library was used to authenticate the API requests (http://oauth.googlecode.com/svn/code/php/).

The Google Document is displayed to the user within an iframe in the VLE. This is not without its problems as within some browsers (mainly Internet Explorer) the document will not always display. To overcome this there is a hyperlink to the Google document always displayed alongside the iframe, so if any issues are experienced it can be accessed directly by the user. Google presentations will not display in an iframe at all (they explicitly deny access in the page header) so presentations will always display as read-only within the VLE and must be edited by the user within Google Docs in a separate tab/window.

Giving the activity access to the Google Docs domain raises issues of user content access. The API can access all accounts on the domain and there is no mechanism to restrict it to certain accounts (even though the activity only needs to access the one account). To prevent the access credentials (key and password) being exposed to VLE developers and administrators at the OU these credentials are obtained from a secured web service that can only be accessed by the live servers.

The tool supports two ‘modes’:

• Scaffold – a collection of folders and files that can be pushed to the portfolio
• Template – A series of items (including user generated) that are collated into a document.

The tool supports two export formats:

• File (rtf document) and Zip (when exporting multiple files)
• Google Docs – can be optionally targeted to a specific Google Apps domain.

Availability of export options to the end user can be configured at a site-wide level and per-activity.

Both ‘modes’ and exports utilise the Moodle sub-plugin architecture, so extra functionality can be developed independently as required.

Scaffolds

When in scaffold mode the activity enables the exporting of the scaffold folders and files to the student’s portfolio. Scaffolds are created by course administrators using the Moodle file form control and can contain folders, sub-folders and files of any type that are supported by Google Docs for conversion to its native format. Scaffolds reside at the course level so can be re-used across any number of portfolio activities. Scaffolds can also be integrated into template mode portfolio activities; in these instances the scaffold has the template document added into it before export.

Editing a scaffold in the module admin interface

Scaffold export to zip file

When exporting to Google docs the structure of the scaffold is represented using collections (‘tagged’ folders). A new collection is added on every export; this can be shared with a tutor/mentor for review or be exported for assessment submission.

A Google Docs account populated with a portfolio export

Templates

When in template mode the user is lead through the activity, filling in entries in the template, culminating in the export of a document that is added to their portfolio. Templates are created by course administrators using the designer interface accessed from the activity. Templates are structured using pages; each page contains and number of items. Items are typically either instructional text or some kind of user entry form field such as text entry or checkbox. Templates reside at the course level and can be reused across any number of portfolio activities.

Portfolio activity template designer interface

Template activities and items are highly configurable, allowing for complex functionality; for example, your template could generate a three page document but its creation by the end user could be split over three activities, each concerned with a separate page.

Portfolio activity - template

Technical challenges

Creation of this module was quite a substantial development and along the way there were a number of challenges that were needed to be overcome.
Firstly, most of the required interactions with Google Docs were not supported in the Moodle libraries. In this development we added some extra features within our module (https://github.com/JISC-DOULS/moodle-mod_portfolioact/blob/master/save/google/lib.php) that work with collections and utilise the resumable file upload feature of the Google Docs API. It would be possible to extract many of these and add them to the core libraries in the future.

Secondly, the complexities of the requirements around reuse of templates across a course caused issues – specifically with the back and restore process. In most activities within Moodle the data is associated solely with a specific instance of the activity; in the Portfolio Activity the template (and potentially user) data is associated with the course. The backup and restore process works at an individual activity level (so whilst backing up a course each activity is processed in isolation) and so there was a need to be wary of duplication e.g. if a template is reused across three activities that are being backed up the template should only be stored once, not three times. In order to overcome this issue checks had to be put into the restore process in the module to ensure that any template was only processed once per process.

These are:

• Portfolio activity Moodle module
• Google collaborative activity Moodle module
• OpenSocial gadget connector for Moodle
• VLE Study planner gadget

The code source generated from the project now has a place to live:

https://github.com/JISC-DOULS

Some of these developments are up in the github area now – note that documentation is a bit sparse at present.

We will hopefully have some blog posts up in the next few weeks detailing these developments and demonstrating their features.

Some will be demonstrated as part of the JISC Innovating e-Learning pre-conference  activity week.

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.

OU study planner gadget on iGoogle

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

Components of the OU study planner gadget

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.

Maximised 'canvas' view of the OU study planner gadget

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.

The specification for the study planner gadget is now linked from the specifications page of the blog.

One aspect of the DOULS project is to improve the integration between our institutional VLE (Moodle) and Google Apps for education (which is available to all students as part of our email provision). A development task in the project is to update the calendar export process so that students can get the data from the VLE into their Google calendar much more easily.
Once in the Google calendar the events should synchronise with data on the VLE so if any events are changed,  for example a tutorial start time, then the Google calendar should reflect this change. There are a number of advantages to using the Google calendar over the Moodle calendar alone as you can then: use the Google calendar gadget to view the information on your homepage (which links in to the other part of the project), get text alerts for upcoming events,  sync the calendar with an Android phone.

This task is now almost complete; there still needs to be some design input so it can integrate with the new VLE design that is currently being developed and it is going to be usability tested by students in the next few weeks to ensure it is easy to use. As with all of the outputs from this project, the code for this development will be made available to the Moodle community once it is stable and ready for release.

This development consists of a Moodle local-plugin that contains a new export interface as well as the logic to generate the calendar data. The advantage of using a local-plugin is that the display and logic can be customised for our needs without having to change any Moodle core code; yet we can still make use of some of the existing code libraries and can even have our custom export process take place instead of the standard one by using a theme renderer override.

The new calendar export process includes the means to directly add the VLE calendar feed the user selected to their Google calendar (a one-click process). It supports standard Google accounts or can be directed to a Google domain where single-sign-in is utilised (such as at the OU).

Some of the key points learnt from the development of this feature were:

• It was our intial intention to use and API to manage calendar subscriptions but the Google calendar API can’t be used to subscribe to an external calendar feed (Open Issue).
• However, you can subscribe someone to a calendar feed by using an ‘add to Google’ button as detailed at: http://www.google.com/intl/en/googlecalendar/event_publisher_guide.html#public. The URL required takes the form http://www.google.com/calendar/render?cid=your_calendar_url - you can replace the standard Google address with a Google Apps domain address if required.
• If  the calendar file/feed has a name defined then this will be displayed in the Google calendar list. Use the iCalendar  property “X-WR-CALNAME” to do this e.g. X-WR-CALNAME:VLE calendar.
• The Moodle calendar can contain events that have a different context e.g. course, site, user. Course events are added to a calendar ‘category’ with the short name of the course; other events are not defined with a category. If a calendar has a mix of items where some have a category defined and some don’t then the Google calendar will often not import all. To overcome this in our calendar feed all items are defined with a category (either the course name or ‘personal’ or ‘site’).