Community hub

Moodle 2.0

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-19309.

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 the peers on a long-term basis.
   • other learners want to find free and for-fee 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.

Overview

The "community hub" is not a product, it's a collection of different solutions that work together:

• directory.moodle.org: an open directory of registered courses that are downloadable or enrollable
• repository plugin in Moodle 2.0: to find downloadable course templates in the directory, download them from the original site and restore them
• community block in Moodle 2.0: to search the directory to find enrollable courses to join

Downloadable courses

• (A) Sites that want to publish certain courses and make them downloadable do so during registration time with the Moodle Directory.
• (B) Later, any Moodle user can connect to the Directory (via Repository API) to search for downloadable courses and choose one (receiving a URL).
• (C) When the Moodle user tries to download the course, it comes from the original site. The original site will send a Moodle archive as a .zip file (can be cached by the server).
• (D) The Moodle user receives the file and can now restore it normally.

Enrollable courses

• (1) Sites that want to publish certain courses for the public to enrol in can do so during registration time with the Moodle Directory
• (2) Later, any Moodle user can connect to the Directory (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 (with or without Mnet).

Use Cases

New teacher creating a course

1. New teacher needs some help with a new course for "Alligator farming 101"
2. Teacher sees "Import/Export" block into the "Alligator farming 101" course page and presses "Import course"
3. Teacher browses directory in the File picker (the data comes from directory.moodle.org by 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 his "Community" block and clicks "Find community".
2. Moodle displays an search courses page (the data comes from directory.moodle.org by 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 "Find community". The selected course is now permanently listed in the Community block.
5. Teacher clicks on the link and is taken to the course, where he can enrol and interact/learn with peers over time, subscribe to forums etc.

Components

There are three main parts to this project:

• Moodle.org directory (+ registration form on Moodle sites)
• Community membership
• Import/Export courses

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 "publish" will be listed.

Data structure

this section concerns how the database tables will look on Moodle.org. This section is about listing all data that Moodle.org should store.

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.

Stats fields:

• number of courses
• number of users
• number of enrolments
• number of posts
• number of resources
• number of questions

Field inherited from previous registry database:

• default site language
• Moodle version (2009050502)
• Moodle release (1.9.5+)
• Site ip address (need to be updated at every update)
• Secret answer
• Mail me the Moodle newsletter
• Can be contacted on the site
• Confirmed
• Time updated
• Time created
• Unreachable
• Time link checked

Field	Type	Default	Description
id	int(10)	auto-incrementing
name	varchar(255)	not null	Site Name
description	text	null	site description
url	varchar(255)	not null	site URL
Physical address	varchar(255)	null	location of the company
manager name	varchar(100)	null
manager email	varchar(100)	null
manager phone	varchar(20)	null
statistic	text	null	stats, text format
moodleversion	varchar()	null	stats, text format

Courses

All registered courses will be stored 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. URL
5. Tags
   1. Standard (mathematics, physics, biology) Always displayed, translatable etc (Course Standard Tags ) Do we need some special tags per country?
   2. User (stuff, openuni, jeromesstuff etc) Not displayed for browsing, but searchable
   3. Metadata standard Dublin Core
6. Country code (AU, FR etc) lang/countries.php
7. Region/state (based on list) ISO 3166-2 (XX-XXX)
8. Language lang.php
9. Availability (public/private)
10. Cost (and currency) ISO 4217
11. Download link: direct URL to Moodle download script or moodle.org cache or somewhere else
12. Guest Access
13. Accounts allowed (can we sign up)
14. Screenshots no references into the "registered_courses" table, all screenshots will be saved into the "files" table and the references to the "registered" will be into this "files" table.
15. Audience: Educators | Students | Admins
16. Educational level being discussed (for educators audience only): Tertiary | Secondary | Primary | Government | Corporate
17. Tool usage stats (number of forums/quizzes/resources etc All core modules - no participant number) Only available for downloadable content.

Field	Type	Default	Description
id	int(10)	auto-incrementing
site id	int(10)	auto-incrementing
name	varchar(255)	not null	Course Name
description	text	null	Course description
url	varchar(255)	not null	course URL
stdtags	varchar(255)	null
usertags	varchar(255)	null
metadata	varchar(255)	null
country	varchar(2)	null
region	varchar(6)	null
language	varchar(30)	null
currency	varchar(3)	null
cost	varchar(10)	null
availability	varchar(20)	private
downloadlink	varchar(255)	null
guestaccess	boolean	false
accountsallowed	boolean	false
audience	varchar(20)	null
educationallevel	varchar(20)	null
stats	text	null

Web interface

A Moodle.org web interface, with a search form, displays clickable links to each course.

From this web interface the users can:

• search by keyword and see a list of courses that match - hightlight key word
• browse a list of courses using the standard tag set (hierarchy, tree on the left)
• 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
• 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
• Date last checked (by a cron job)
• Audience (teachers, students, admins)
• Teacher name(s) - Sortable

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?

Registration on Moodle sites

The existing Moodle registration form will be extended so that admins can choose to send in more info about their sites to the Moodle.org directory. All courses flagged "Register" 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.

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). If a user has not the capability, he will not see the "Community" block.
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.

File:Blocktemplate.png

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 (if the portfolio plugin is activated)
• 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. He's also asked to upload screenshots if he'd like to.

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).

Course settings page

Some new settings will appear on this page:

• register on Moodle.org - a sub option is activated by default: publish (the site will be displayed in the search result on Moodle.org)
• cache on Moodle.org
• downloadable
• metadata
• screenshots

Schedule

Full schedule and progress is in the tracker: MDL-19309

1. Moodle.org directory
2. Web interface
3. Web service interface
4. Improve registration form
5. Community block
6. Publish courses
7. Import courses
8. Export courses

See also

• Community hub technotes - relating to MNet developments in Moodle 1.8
• MDL-18580 - Community Hub tracker issue