Optimizing the Pedagogy, Software and Content Formats for On-line Courses

A few days ago the Australian National University (ANU) announced it had joined the edX consortium and would start offering Massive Open On-line Courses (MOOCs) from 2014. I have been running an on-line courses for small numbers of students at ANU since 2009, so decided to see what was needed to use the content for a MOOC. Here I have discussed general issues. At present I don't have any technical or procedural details of how edX is implemented.

Content

The content for my courses is already free open access, so that removes a major impediment to making it widely available. Also I prepare my course notes in a format designed to meet accessibility standards and require minimal system resources. I did this because Australian law requires access for the disabled and also because some students are in remote locations with low bandwidth connections. In practice this is a matter of using a simple layout for documents, with default formatting. The content then easily translates into the content delivery system used. Originally I used lots of separate notes in different formats, but now consolidate all the noes for a course into a HTML formatted e-book, using the Moodle book module. Hopefully edX has a similar feature.

Pedagogy

I designed course content so it can be downloaded and used off-line. This is to help with locations where the student has only intermittent Internet access. Providing off-line access also helps with student learning: the student has a reasonable chunk of work to do (either alone or in a group), before asking their tutor or fellow students about it. I will be discussing this form of synchronized asynchronous learning in a presentation at ICCSE 2013 (a preprint of the paper is available).

On-line university courses will typically group students into cohorts of about two dozen and encourage the students to get to know each other and their tutor. MOOCs seem to be still trying to find a way to reproduce this approach, with students forming their own on-line study groups. Clearly it is unworkable to have thousands of students in one group and so tools are needed to have then forum smaller groups. There have been reports of problems with this in some MOOCs, with the tools for students to select their group not being able to cope with the load. It will be interesting to see how edX handles this.

Software

Courses are usually delivered at institutions using specialized Learning Management System (LMS) software. ANU uses Moodle and much effort is put into making sure that there is sufficient capacity for the more than ten thousand students. Even so, like many of my colleagues, I also provide a copy of course notes outside the LMS, on an ordinary web site, in case of access problems. This is also useful for students who have not yet completed the formal enrollment process, and so do not have access to the LMS, but want to start work.

Hundreds of thousands, or millions, of students creates a very large load for the LMS. Today Coursera reported: "We're currently experiencing server issues. Stay tuned to status.coursera.org. Thank you for your patience.".

I have some experience at diagnosing problems with on-line systems used for emergency warning and disaster recovery. These systems experience high loads during an emergency. The usual response is to increase server capacity, but if you have very high loads this can be ineffective. It is possible to carry out a quick examination of the system and usually identify a few hot-spots which can be fixed to increase the system capacity by hundreds or thousands of times. One problems is customization of content for each user unnecessarily, thus preventing caching working. Also video and images in the wrong format, resulting in very large files can be a problem. Another problem is to offer  content to the user before they ask for it, thus wasting system resources and their time.

In the longer term it should be possible to break the LMS into a number of independent parts to make it more efficient and reliable. Google have taken an interesting approach with their "Google Course Builder", by essentially having the courses hand crafted using HTML and JavaScript. This approach will not work for the average course designer, which does not have that level of technical skills, but might be workable with some front end tools to generate the needed code. The result could be something like a compiler for computer software, which produced code which is very efficient to run, but the penalty being changes are harder to make. The LMS can instead be thought of as an interpreter of the course-ware: easier to make changes to but much less efficient to run.

Where are teacher has a few dozen, or few hundred, students they can simply make a change to the course and tell the students, answering any queries. But of there are millions of students such ad-hoc changes will cause chaos. It may be that course designers will need to learn some of the same skills of software engineers use to systematically make changes to a large system, so as to cause least inconvenience to those using it.

Some MOOC providers seem to be attempting to avoid the problem of supporting a large system by using other services in place of their own, such as Google and Facebook. But this may simply transfer the problem somewhere else and also can result in privacy problems. Universities offering courses in Australia are subject to federal privacy laws. It is reasonably simple to configure the in-house LMS (even an outsourced one) to meet the legal requirements to protect student information. But if the students are required to use an external social networking site as part of their course, then ensuring privacy becomes more difficult.