Development:Community hub

This page describes a functional spec for the "Moodle Community Hub" project, which consists of several new features in Moodle 2.0.

The tracker issue for this project is MDL-18580.

Goals and rationale

The goals of the Community hub project are:

1. to allow educators to find and join communities of practice around the world. Such communities (or "hubs") could be subject or region-oriented, allowing teachers to easily associate with their peers on a long-term basis.
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.

Overview

The solution consists of several parts in Moodle.

• an open directory of registered community sites and courses on directory.moodle.org
• a new block in Moodle 2.0 to search this directory to find courses/hubs to join
• new repository plugins in Moodle 2.0 to download and restore courses from registered hubs

Components

There are three main parts to this project:

Moodle.org directory

A new directory system (hosted at directory.moodle.org) will allow users to browse and search registered courses and hubs around the world. This data is collected from site admins when they register their Moodle site on an "opt-in" basis. Only courses that are marked as being open to outside enrollment will be listed.

Data structure

Sites

This information will be used for general statistics, as well as the directory.

1. Site name
2. Site description
3. URL
4. Physical address
5. Site manager (name, email, phone)
6. Contact form yes/no?
7. Mnet/WS information, enough to let a teacher authenticate to the site using Mnet 2.0 (optional)
8. Tool usage stats (forums/quizzes/resources etc) Not for public viewing.

Courses

All public courses will be listed here. Some will be looking for students, some will be teacher and admin communities, and some will be downloadable course templates.

1. Site
2. Name
3. Description
4. Tags
   1. Standard (mathematics, physics, biology) Always displayed, translatable etc define them
   2. User (stuff, openuni, jeromesstuff etc) Not displayed for browsing, but searchable
   3. Metadata standard (Dublic core? LOM?) choose the simplest
5. Country code (AU, FR etc)
6. Region/state (based on list)
7. Language
8. Availability (public/private)
9. Cost (and currency)
10. Download link: direct URL to Moodle download script or moodle.org cache or somewhere else
11. Audience: Educators | Students | Admins
12. Educational level being discussed (for educators audience only): Tertiary | Secondary | Primary | Government | Corporate
13. Tool usage stats (number of forums/quizzes/resources etc) Only available for downloadable content.

Registration

The existing registration form will be extended so that admins can choose to send in more info about their sites to the directory. All courses flagged "Publish" are also sent with their full details.

A cron job will be added to Moodle so that each site can automatically inform directory.moodle.org later when course information is updated (if the admin allows it).

Moodle.org will perform a heartbeat ping every week to verify that the site is accessible. Sites that fail two or three in a row will be removed from the directory.

Web interface

A web interface, with clickable links to each course so that users can log in there.

From this interface the users can:

• search by keyword and see a list of courses that match
• browse a list of courses using the standard tag set
• go directly to a course (if marked for public use)
• preview a course (if screenshots have been provided)
• download the course to desktop (only if an download url has been set)
• give a rating to the course

When displaying courses, you can see and sort by:

• Title
• Description
• Tags
• Screenshot(s)
• Cost (if any)
• Rating (10-point scale displayed as 5 stars, and only if you are logged in to moodle.org)
• Moodle site name
• Date added to directory
• Date last updated in directory
• Date last checked (by a cron job)
• Audience (teachers, students, admins)
• Teacher name(s)

Web service interface

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?

Community membership

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

It can be added to any page for any user, and contains:

1. A link to a search script, with a new capability to view it (default on for teachers, not students)
2. A search script to browse/search the directory (using web services to call Moodle.org). Users can select joinable courses from the list and they will be added to the list of "subscribed" course links in the block contents (grouped by site).

If the course is on a site with mnet enabled in "open hub mode" then the link will take the user directly to the course and they will stay logged in. Otherwise the link will be just be an ordinary URL and the remote site will be responsible for authentication.

Import/Export courses

The Import/Export block will be available on course pages and contains buttons to:

• Export course: publish entire course (as Moodle Backup minus userdata) as a course template to a Moodle Hub (Portfolio API plugin)
• Import course: find/install a course template from a Hub or from another course on same site (Repository API plugin)
• Publish course: to publish or update the description of the current course in the Moodle.org directory (admins only)

Export course

A standard export will do a normal backup (taking care to remove userdata by default), and at the end will call the portfolio API to push that file to a connected portfolio. These could include:

• downloading it to the local computer
• uploading it to any general purpose repository
• uploading it to a Moodle Hub site already set up with Mnet peering.

Pushing it to a Moodle Hub would trigger extra behaviours:

• More metadata would be required (including screenshots?)
• Permissions would be checked on the destination Moodle
• The course can be immediately restored on the external Moodle in a special "New" category as a hidden course
• Someone on the external Moodle can be alerted to approve/unhide the new course

Import course

The Import course button will pull up a normal file picker to browse repositories for files with a mimetype matching .mbkup.zip.

One special repository plugin called "Courses" allows the user to:

• search the moodle.org directory for downloadable courses (only)
• directly search any connected hubs for downloadable courses
• search other courses on the same server (replacing the existing import function we have)

Once the user has selected one of these courses, the user is passed to the standard restore process.

Publish course

The Publish button only exists if the current site has been registered on the Moodle directory already, and if the current user has the appropriate capabilities.

After clicking "Publish" the user will get taken to a script asking if you want to allow downloads of this course.

If downloads are allowed, then you are redirected to the backup process to create and define the backup file, then returned to the script if successful. The backup file is cached in a standard place with a standard name. If downloads are not required then this step is skipped.

Now the script lists the metadata that this course will be published with on the moodle.org directory (this is also available in the course settings page). After checking/updating the metadata, the script will push the data to the Moodle.org directory. The Moodle directory will bounce back a confirmation which gets saved locally as the "Last publish date".

If the checkbox to allow download was checked, then the URL to a course download script is included with this metadata.

The course download script (eg /course/download.php?id=55&secret=XXXXX) will send the cached .zip file for the given course, or (if the the admin has specified that automatic updates are allowed and the course has also allowed it, then it might update the cache once a day or something).

Schedule

Full schedule and progress is in the tracker: MDL-18580.

1. Moodle.org directory
2. Web interface
3. Web service interface
4. Improve registration form

See also

• Community hub technotes - relating to MNet developments in Moodle 1.8