XS Moodle design

From OLPC
Revision as of 14:14, 27 November 2008 by Martinlanghoff (talk | contribs)
Jump to: navigation, search

These are notes on the design of how we want Moodle to work in the XS. The implementation work that gets us there is described in XS_Moodle_plans.

Changes to support education goals

These design notes come from lengthy discussions with the education team @ OLPC, and cover how to get Moodle to be more approachable for the 6-12 age group, and how to emphasize its constructivist strengths.

Straight into the course and current content

When users go the 'School Server' they land in Moodle, and will usually be wanting to see "today's material" as prepared by their teacher. We want to minimise the chances of them getting lost in the navigation.

Most users will only be enrolled in 1 course. As soon as they are logged in (which is planned to be automatic), users that are enrolled in one course should be redirected there immediately.

The course format must default to displaying the current 'topic'.

Topics-style course format, geared for a year-long

The topics course format needs improvements to support year-long usage. We want to encourage teachers to use the Moodle course page to provide content links and the starting point for the activities of the day.

Some teachers will want to use quite frequently - several times per week. Our goal should be to be able to support using it every day through the year. Such usage represents an extreme -- we just have to make sure no technical issues limit it.

  • It has to normally just show the current topic. "All topics" must be explicitly requested and soon forgotten. Perhaps an intermediate "5 topics at a time" pagination can be added.
  • Consider reversing the ordering of topics in "all topics" and "paginated" views -- this will get it into blog-style.
  • A new course will be started with one or two topics only - we need a button to 'add a topic' for users with edit capabilities.

What You Paint Is What You Get editor

For younger kids, drawing and painting dominates over text. Most of Moodle's text-oriented tools can be made approachable for work with 6-12s if we can add a "paint right here" facility to our WYSIWYG editor. See discussion of possible tools at [1]

With this in place the teacher can make course labels much more lively, and kids can be asked to paint straight into a forum post, blog entry, etc.

Emphasize blogs, interlink to course page

Part of the constructivist approach is to get kids into doing small projects. The blog for them is a favourite as a personal and project journal. However, they still want it somewhat course-scoped (which means year-scoped), so the plan is to use ou_blog.

Both blogs are quite segregated from the main course page. So we want

  • Emphasized links to "my blog" and "my course blogs aggregate"
  • Links back from the blog views to the course

In a sense, ou_blog being a more traditional module has better navigation than the standard blog so the job is easier on that track too. However, we'll need to

  • Replace the 'blog' tab/page in the user page with an ou_blog controlled page

Change of year admin tools

We will hide all the complex course settings, as they are mostly irrelevant. However, some are extremely important at end-of-year time. We'll have a page specifically for those tasks - for example:

  • We need tools to create a new course for a group that's moved up a year...
    • migrating all the enrolments to the new course
    • using a given course as 'content template' (hiding all the topics)
    • archiving the now old course
  • Other end-of-year/change of year tools?

Most of this already exists but is fiddly. We need a streamlined tool for this.

Zero Administration

The Moodle install on the OLPC XS server is completely automated -- no need to go through the "install" process (which performs the database setup, asks for configuration info and creates an administrator account).

  • We use the cli installer/updater to perform a full installation. This creates an admin user account and hides the password in /etc/moodle -- this should not be used.
  • All settings are preset. All values that reside in config and config_plugins settings are preset, either in config.php or in post-installation scripts.
  • We create user accounts for all the users registered via idmgr (so we can later auto-login)
  • The first user to ever connect to Moodle, gets to have a special "staff" role sitewide...
  • The Staff role can perform some limited administration
    • Grant/revoke staff role to other users
    • Create new courses
      • We want a course creation process that is streamlined -- skip the course settings page, and enrolment steps. Create the course with presets, load a content template, auto-enrol the creator as teacher, and put the user directly in the course page.