Development:Community hub

• PROJECT STATE: implemented
• MAIN TRACKER ISSUE: MDL-19309
• DISCUSSION AND COMMENTS: Hub servers forum in Using Moodle
• MAIN AUTHORS: Martin Dougiamas and Jerome mouneyrac

This page describes an overall functional specification for the "Moodle Community Hub" project, which consists of a new system (the Moodle Hub Server) and several new features in Moodle 2.0.

Goals and rationale

The main goals of the Community hub project are:

1. to allow people to easily find courses around the world that they want to enrol in:
   • educators want to find communities of practice that are subject or region-oriented, so that they can associate with their peers on a long-term basis.
   • other learners want to find and study courses on various other subjects
2. to make it easy for educators to find and download course templates from other people. This will help educators share and identify examples of best practice in online pedagogy and hopefully improve the average quality of online courses.

Finally, we want to do all this in the simplest, safest way possible, while allowing a range of scenarios such as courses that are public or private, free or paid, so that the Moodle community can build solutions for themselves.

Overview

The diagram below shows the basic idea. The systems in this diagram are:

Ordinary Moodle site

A typical Moodle site with teachers who want to download course templates and/or users who want to connect (enrol) with external communities

Publishing site

A Moodle site that wants to make some of its courses available for download

Community site

A Moodle site that provides courses that are enrollable

Moodle Hub Server

A new Moodle plugin for listing registered courses that are downloadable or enrollable. The default hub will be installed at hub.moodle.org, but there can be many others.

Downloadable courses

• (A) Sites that want to publish certain courses and make them downloadable can register them with one or more Hub Servers.
• (B) The Hub will check the data and make sure the course zip is downloadable, caching a copy locally. The Hub may also have a security process to check the download for trojan horses, bad content, etc.
• (C) The download process may trigger the backup process on the original server if it hasn't been done already.
• (D) Later, Moodle users (who have permissions to do so) can connect to a Hub to search for downloadable courses and choose one.
• (E) The Moodle site downloads the file and makes it available to the Moodle user so they can now continue to restore it normally.

Enrollable courses

• (1) Sites that want to publish certain courses for the public to enrol in can register them with one or more hub (including the main one at moodle.org)
• (2) Later, any Moodle user can connect to a hub (via Community block in their site) to search and find courses they want to join
• (3) They click on a link to be sent to the other site so that they can enrol there.

Use Cases

New teacher creating a course

1. New teacher needs some help with a new course for "Alligator farming 101"
2. Teacher sees the "Community" block into the "Alligator farming 101" course page and presses "Search course"
3. Teacher browses a list of downloadable courses in the community page (the data comes from one or more Hubs via web services)
4. Teacher searches for "Alligator"
5. Teacher finds 4 courses that look good, and after reading reviews and ratings, chooses one.
6. The course is downloaded and unpacked in Moodle.
7. The teacher now has a good starter course they can keep developing.

New teacher needs help

A teacher decides they need some help and wants to talk with others teaching Alligator farming.

1. Teacher goes to their "Community" block and clicks "Search course".
2. Moodle displays a page to search for courses (the data comes from one or more Hubs via web services)
3. Teacher searches courses for "educator" courses on "Alligators" in their country/language.
4. Teacher finds two, selects one, and is returned to the page where is was before clicking on "Search course". The selected course is now permanently listed in the Community block.
5. Teacher clicks on the link and is taken to the course, where they can enrol and interact/learn with peers over time, subscribe to forums etc.

University consortium

A group of five universites wants to share courses among themselves and not to the outside world. They also want to prevent teachers from downloading courses from outside the consortium.

1. Someone downloads Moodle and installs it as a private Moodle Hub Server
2. Admins of all five Moodle sites in the group add the URL of the private Hub to their settings and register their sites there
3. The default Hub at hub.moodle.org is (optionally) disabled in the site-wide settings.
4. Admins register their courses with the Hub.
5. Teachers can now import, export or join courses via the private Hub.

Course creation business

NOT IMPLEMENTED

CoolCourses Inc have produced a set of 50 good Moodle courses which they wish to sell.

1. They set up a Moodle site with all their courses in them.
2. They set up a Hub with a payment system, and register it with the Hub List at moodle.org so people can find it
3. They register all their courses with their own Hub with appropriate metadata
4. When looking for courses, users can either
   • find this Hub by browsing through the Hub List, or
   • type the URL of the Hub directly into their Moodle site
5. When users try to download a course, they may see a payment button to download it (credit card, paypal etc)
6. CoolCourses could provide limited access to the courses on their Moodle site using Roles, as a preview.

Components

There are several components:

Hub List

A list of known Hub Servers, kept on moodle.org

Hub Server

A new Moodle plugin for publishing a list of registered courses that are downloadable or enrollable

Course registration

A new mechanism in every Moodle to register particular courses with one or more Hub Servers

Community membership block

to search Hub Servers to find enrollable courses to join and bookmark

Import/Export block

Makes it easy to find downloadable course templates in a Hub Server, then download them from the Hub Server and restore them locally

Moodle Hub List

The Hub List is a list of known Hub Servers (see the next section). This makes it easy for Moodle users to find the most appropriate Hub Servers for their needs. To get on the Hub List, Hub Servers choose to register with moodle.org via their administration interface.

Moodle.org will store the following information, and make it available via a browseable interface at hhttp://hubdirectory.moodle.org/.

Moodle Hub Server

Mockup: hub registration page

The Moodle Hub Server (aka Hub) is a separate system (based on Moodle technology) that allows Moodle sites to register their courses for listing there. More technically, the hub server is a Moodle plugin.

A default installation of this software will be running at hub.moodle.org, but anyone else can download it and set up their own hub for private or public uses. A hub can also be used as a Moodle site, even though the Moodle front page will be replaced by the hub front page.

Hubs can optionally register themselves in the Hub List so that they are easier to find and so they can become a "Trusted Hub".

A hub server has some config fields (saved into its database):

• name (site name by default, changing the value here, do not change the site name)
• description (front page summary as default value)
• language (choose the language, set site language as default)
• contact name (current user by default)
• contact email
• enable
• password (only for private hub)
• logo url (need to have a limited size of 150x150)
• protected web search interface (TODO: MDL-24015)

Data structure

Most of the data structure can be found in the community hub technical specification.

User interface

Mockup: search course UI

If visiting the hub via the web, it will provide an interface for full searching and browsing.

The web interface can be protected from access. The hub at moodle.org will of course be open to all.

Mockup: search hub UI

The web interface allows users to:

• search by keyword (descriptions, titles, tags, subject etc)
• browse a list of courses by subject
• go directly to a course (if marked for public use)
• preview a course (if screenshots have been provided, or the original URL location)
• download the course to desktop (only if an download url has been set)
• If logged in to the Hub, users can also:
  • give a rating to the course
  • write a comment for the course - use comment 2.0 API

When displaying courses, you can see and sort by:

• Title - Sortable
• Description
• Tags - Sortable (first tag retrieved by the request is considered)
• Screenshot(s)
• Cost (if any) - Sortable
• Rating (10-point scale displayed as 5 stars, and only if you are logged in to moodle.org) - Sortable
• Comments
• Moodle site name
• Date added to directory
• Date last updated in directory
• Audience (teachers, students, admins)
• Teacher name(s) - Sortable

Web service interface

TODO: MDL-24031 A REST-based web services interface will be provided for other systems (eg Moodle sites) to use directly.

Web services can search on:

• string search
• array language
• array cost
• array Moodle url
• Others?

Hub admin interface

The hub will have a Hub admin interface. Admin processes include:

• Listing, approving and editing the sites registered with the hub
• Listing, approving and editing the course descriptions, metadata etc.
• Registering/updating the Hub with the Hub List
• Configuring Hub behaviour and the appearance of the home page.

Course global search functionality

In order to quickly search a course on all public hubs, Moodle.org will have a table equivalent to the course 'directory' table with dew additional field as "public hub id", "site url", "site name"...

Site registration

Mockup: site registration UI

The existing site registration form in Moodle will be extended so that admins can:

1. choose one or more Hubs to register with (hub.moodle.org and/or others in the Hub List, or directly to a particular Hub specified by URL)
2. choose to enable cron to re-send statistics to the hub on a periodic basis. (TODO/TBD)
3. choose to enable the hub to harvest courses on a periodic basis (TODO: not shown on image/TBD)

Community membership

The "Community" block allows people to find and subscribe to external courses that they want to be part of.

Visibility of the block and the features within it are controlled by roles, and contains:

1. 'Bookmarks' of previously-selected (subscribed) external courses (to make revisiting easy) grouped by site, which can be edited/deleted etc
2. A link to a search script - "Add new courses..."
3. A search script to browse/search one or more Hubs (via web services to get the data, with the interface rendered by the local script). Users can select joinable courses from the list and they'll get added to the list in the block.

Generally the links will be just be an ordinary URL and the remote site will be responsible for authentication.

If the foreign site has an Mnet connection set up with the current site then login will be immediate.

Mockup: community block

community block database structure:

Name	Type	Description
id	int	Standard autoincrement
userid	int	foreign key - ID of the user
coursename	varchar	Name of the community course
coursedescription	text	Description of the community course - display by the tag link
courseurl	varchar	The full URL to the community course front page
image	varchar	community course logo url - it could be displayed as icon

Publish courses

Publish course: to publish or update the description of the current course in one or more Hubs

The Publish button only exists if the current user has the appropriate capabilities and if the current Moodle site has been registered with a Hub.

Mockup: course publishing

Choosing "Publish" goes to a script where you can chose from the registered Hubs and whether you want to publish the course as:

• enrollable/advertise, so that others can come here and use the course where it is, and/or
• downloadable/share, so that a Hub can offer this course for download to others

If the user wants to offer this course for download, then they are directed to the standard backup process to create and define the backup file (without users!). If the backup is successful the zip is stored in a standard place and then the user is returned to the publish script to continue. (If downloads are not required then this whole step is skipped).

It allows the user to set up full , and especially whether you want to advertise this course as being:

Now the script presents a form with metadata that this course will be published with on the chosen Hub(s) (this is also available in the course settings page). Metadata includes information such as description, licensing, categories, screenshots etc (see the Courses section above for more info).

After checking/updating the metadata, the script will push the data to the selected Hub.

If the checkbox to allow download was selected, then the URL to a course upload script in the current Moodle is included with the metadata. This URL contains a token (eg an MD5 stored in the course table) that only the Hub knows.

The course upload script (eg /local/hub/webservice/upload.php?id=55&token=XXXXX) will expect the cached .zip file for the given course.

Publish course settings

Some publish settings and info will also be available anytime via the course settings page under a "Publish" tab:

• Which hubs has this course been published on, and when
• Full metadata
• Screenshots

Harvest courses

NOT IMPLEMENTED Note: site to hub communication is one way only, the following text may change.

Each hub will use cron to call every site that has registered a harvesting url on a periodic basis. This will be done at the same time as the link is checked to ensure the site is reachable, so the "time link was last checked" field in the site table also indicates when the site was last harvested.

The harvesting url will be an RSS feed which will list all the courses to be included in the hub and their metadata. This might be the feed of all visible courses on the site, or courses in a given category. TODO: should we allow them to enter multiple category feeds so they can say "arts", "business" and "languages" but not "science"?

Course list RSS feeds are an existing tracker item for Moodle 2.0 See http://tracker.moodle.org/browse/MDL-13248 This patch allows admins to pick which categories have individual feeds created and are included in the "all courses" feed. Each course becomes an <item> in the RSS feed as follows:

• <category> the Moodle course category in which the course belongs
• <title> the course fullname
• <link> the course url
• <pubdate> the date the course (or any of its resources and activities) last updated
• <description> the course summary

The current tracker item will need to be extended to include appropriate course metadata in the RSS feed. There is a Dublin Core extension to RSS 2.0 which can be implemented.

TODO: If we choose an alternative metadata format we will need to locate or create an alternative RSS extension. There is a LOM extension but not from an official IEEE namespace.

We will need to declare our own namespace RSS extension to identify whether a course should be listed in the hub as downloadable and/or enrollable. This extension will add tags to the RSS feed as follows:

• <moodlehub:downloadable>
• <moodlehub:enrollable>

Both tags will take either "yes" or "no" values and will be set by course creators at the same time as they enter course metadata.

The hub will check the published date for each item in the RSS feed to identify whether it needs to update its records. TODO: if we use OAI-PMH for harvesting we can request courses updated since x see http://moodle.org/mod/forum/discuss.php?d=127488

If the course has been updated and is <moodlehub:downloadable> is yes, then the hub will request the site to create a new backup of the entire course (less user data).

See also

• Community hub
• Development: community hub technical specification