XS Moodle design
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.
Easier to embed images
In the WYSIWYG editor the workflow to select and embed an image should be simplified. Right now it is an overly complicated, even legalistic process (it won't let you add the image until you provide an "alt" text).
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
XO Journal smarts and classroom usage
Note - this workflow won't be easy to achieve - but it is interesting to consider.
The XO is backing up to the XS, to a location that Moodle can see. It would then be possible for a teacher to
- Ask kids to open Paint.xo (or other document-creating activity), and make their session shared
- After the class is finished, see all the recently saved shared documents for a class group, all together, in a gallery-style view in Moodle.
Right now, the backup process runs once a day and the time it happens is somewhat random. So there are no guarantees that all the documents will be on the XS when needed. We may be able to rig the journal save action to trigger a backup run if the document was shared -- this in turn may have scaling issues for larger schools.
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.
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.