Note: You are currently viewing documentation for Moodle 2.5. Up-to-date documentation for the latest stable version of Moodle may be available here: Community hub.

Development:Community hub: Difference between revisions

From MoodleDocs
Line 119: Line 119:
* URL
* URL
* Address
* Address
# Country code (AU, FR etc) <span style=color:blue>lang/countries.php</span>
*# Country code (AU, FR etc) <span style=color:blue>lang/countries.php</span>
# Region/state (based on list) <span style=color:blue>ISO 3166-2 (XX-XXX)</span>
*# Region/state (based on list) <span style=color:blue>ISO 3166-2 (XX-XXX)</span>
# Street address  
*# Street address  
*# Geolocation (for mapping)
* Site manager
* Site manager
*# Name
*# Name
Line 150: Line 151:
** median course size
** median course size
* Subscribed to securityalerts@lists.moodle.org
* Subscribed to securityalerts@lists.moodle.org


==== Courses ====
==== Courses ====

Revision as of 07:50, 5 June 2009

Template:Moodle 2.0

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.

Full details about progress for this project are in the tracker: 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.

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.


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 open source web application for publishing a list of registered courses that are downloadable or enrollable. The default hub will be installed at hub.moodle.org, but there can be many others.


Community.png

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 (automatic and/or manual).
  • (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 (via the Repository file picker) to search for downloadable courses and choose one (receiving a download URL).
  • (E) The repository API 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 CDS (including the main one at moodle.org)
  • (2) Later, any Moodle user can connect to a CDS (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 a list of downloadable courses in the File picker (the data comes from a CDS 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 his "Community" block and clicks "Find community".
  2. Moodle displays a page to search for courses (the data comes from a CDS 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 "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.

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 and installs a private Course Directory Server.
  2. Admins of all five Moodle sites in the group add the URL of the private CDS to their settings.
  3. The worldwide CDS at directory.moodle.org is (optionally) disabled in the site-wide settings.
  4. Admins register their courses with the CDS.
  5. Teachers can now browse, join and download courses from the private CDS.

Course creation business

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 the courses in them.
  2. They set up a CDS with a payment system, and register it with moodle.org
  3. They register all their courses with their CDS
  4. When looking for courses, users can either
    • browse through the CDS list from moodle.org, or
    • type in the URL directly into their Moodle
  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 Server
A new open source web application 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
Hub repository plugin
Makes it easy to find downloadable course templates in a Hub Server, then download them from the Hub Server and restore them locally
Hub community block
to search Hub Servers to find enrollable courses to join and bookmark


Moodle Hub Server

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.

An instance of this software will be running at hub.moodle.org, but anyone else can download it and set up their own hub.

Hubs can also register themselves on moodle.org in the meta-list so that they are easier to find and so they can become a "Trusted Hub".


Data structure

Sites

Primarily this table will store information about the sites that have registered course information on that Hub. On hub.moodle.org this information will also be used for general statistics and the listing of registered sites.

  • Id
  • Site name
  • Site description
  • URL
  • Address
    1. Country code (AU, FR etc) lang/countries.php
    2. Region/state (based on list) ISO 3166-2 (XX-XXX)
    3. Street address
    4. Geolocation (for mapping)
  • Site manager
    1. Name
    2. Email
    3. Phone
  • Contact form yes/no?
  • Default site language
  • Moodle version (eg 2009050502)
  • Moodle release (eg 1.9.5+)
  • Site ip address (updated at every update)
  • Unique SiteID code generated by Moodle site
  • Confirmed by admin
  • Mnet/WS information, enough to let a teacher authenticate to the site using Mnet 2.0 (optional)
  • Time updated
  • Time created
  • Currently unreachable
  • Time link was last checked

Extra information that will only be kept on hub.moodle.org (only published in aggregate form):

  • Tool usage stats
    • number of courses
    • number of users
    • number of enrolments
    • number of posts
    • number of resources
    • number of questions
    • median course size
  • Subscribed to securityalerts@lists.moodle.org

Courses

This table stores registered courses, one record per course. Some courses will be "downloadable", some will be enrollable, so different fields can be used.

  • Site ID (foreign key to sites table)
  • Dublin Core Metadata Element Set, Version 1.1
    1. Contributor - course manager names or whoever the publisher nominates
    2. Coverage - User tags
    3. Creator - main teacher name or copyright holder or whoever the publisher nominates
    4. Date - date this was last published/updated
    5. Description - course description
    6. Format - zip / url
    7. Identifier - course shortname (unique on the original site)
    8. Language - based on lang.php
    9. Publisher - the name of the person who caused this record to be entered here
    10. Relation - the site id that it came from
    11. Rights - one of a standard set of open source, creative commons and other licenses
    12. Source - original URL of the course
    13. Subject - The best-matching item from (Course Standard Tags )
    14. Title - Course fullname
    15. Type - "course" (later there might other types such as activities or SCORM packages etc)
  • Audience: Educators | Students | Admins
  • Educational level being discussed (for educators audience only): Tertiary | Secondary | Primary | Government | Corporate
  • Is a course map supplied? (Simple XML description of course structure, could be rendered graphically later CompendiumLD )
  • Course profile
    • Number of Assignments
    • Number of Chats
    • Number of Choices
    • Number of Databases
    • Number of Feedbacks
    • Number of Forums
    • Number of Glossaries
    • Number of Hotpots
    • Number of Labels
    • Number of Lessons
    • Number of Quizzes
    • Number of Resources
    • Number of Scorms
    • Number of Surveys
    • Number of Wikis
    • Number of Workshops
  • Availability (public/private)
  • Download URL (usually a local cached zip but could be anything else, including empty for non-downloadable)
  • Original Download URL (usally a download script on the original Moodle site, used by Hub to get cache)
  • Is the course enrollable anyone with an account?
  • Is guest access allowed?
  • Are screenshots supplied? (stored on disk under id of this record)
  • Enrol Cost (and currency) ISO 4217
  • Download Cost (and currency) ISO 4217

Web interface

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.


XXX STILL WORKING BELOW HERE XXX


Webinterface.png



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.


Registrationform.png


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.


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

Publishtemplate.png

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