EdX platform

The OpenEdX platform is an open-source learning management system for MOOCs. Upon visiting EdX.org, learners were asked to register, and were able to browse lists of courses. Upon selecting a specific course—for example our MOOC, INQ101x: Teaching with Technology and Inquiry—they then entered that course (see Figure 35). Students first landed on the "News" page,

and were then able to use the navigation bar on top to go to see the syllabus, visit the forum or see their own progress. However, most of the interaction with the course happened through the Course tab, depicted in Figure 36.

Figure 36 - EdX screenshot

In the left sidebar was an accordion-style menu with headers that could expand to show activity sequences. Traditionally, courses use weeks as an organizing principle, but we also added sub- menus for course information and course shortcuts. Each of the activity sequences can consist of a number of xBlocks, displayed as row of icons above the content. These xBlocks can be videos (displayed above), text, quizzes, peer-review or built-in interactive exercises and simulations, or external LTI components.

The EdX platform has a number of limitations when it comes to enabling complex pedagogical scripts:

• Although the user interface suggests a certain sequence, students are free to jump to any component that has already been released to the whole course—there is no possibility of making access to B conditional of students having already completed (or even visited) A. • Some of the functionality that we had initially hoped to use was not flexible enough for

our needs. For example, the peer-review functionality only offered a single possible mode of use where students first have to submit a product for review, before they are able to review other people's submissions. This constrained functionality did not allow for other designs, such as having a small subset of students producing lesson designs that serve as learning content for the larger community..

• The discussion forum is not scriptable, with no API to allow automated insertion of messages. It only allows for grouping students into cohorts, and designating certain discussions as specific to each cohort (ie. members of a given cohort only see messages from other members of the same cohort). There is no API for adding students to cohorts, instead a CSV file of students and cohort-assignation must be uploaded manually. • While the xBlocks functionality allows instructional designers to design complex

functionality that integrates deeply with the EdX platform, courses on EdX.org do not currently allow integrating any custom xBlocks.

Edx.org hosts an official version of this software, which offers courses from a variety of universities around the world. Because of the open source licensing and active developer

community, I was able to install and host a version of the OpenEdX software using my Macbook Pro laptop as a server, and thereby have full access to modifying the source code, and developing custom extensions using the xBlocks extension mechanism. Still, with courses hosted on

EdX.org, instructors are limited to using the existing code base and the built-in functionality. The use of the LTI protocol allowed me to develop all custom scripting and orchestration software outside of EdX, with seamless integration of users (i.e., single log-in and authentication).

5.2.7.2 External server and LTI

Learning Tools Interoperability (LTI) is a protocol for connecting external tools to learning management systems, and it is the only feasible way of extending EdX.org courses with rich functionality. External components can either be embedded in a frame in the EdX interface, or

open a new webpage. Requests from EdX to the external tool are cryptographically

authenticated, and contain some metadata about the current user. LTI tools can optionally submit grades back to EdX.

While some existing Web 2.0 tools support LTI integration, most do not, and even those which do might not let us configure the way in which they should be used (such as respecting

grouping). We overcame this by providing most of the functionality through a custom-built server software, and by proxying access to external tools through the LTI server. This allows the development of discrete LTI activities that can be seamlessly scripted into a learning design. It also defines a wide space scripting and orchestration of complex inquiry designs, including KCI and related active learning designs. This will be further discussed in Chapter 6 under Future Research.

The first LTI activity provided to our MOOC participants was to complete the pre-course survey, which also served to register them an interactive user (see Group formation, above). Because this component was launched by the student explicitly clicking a button, and acknowledging that their private information will be transferred to an axternal component, we could receive the EdX username and password from EdX, together with a student identifier. The username enabled us to connect learning analytics information from the LTI server with data exports from EdX, and the e-mail enabled us to contact individual students directly. The registration portion was done as the very first part of the survey, and in fact, the remaining portions of the survey were presented as optional (90% of all those who completed the registration went on to complete the survey). All of the responses to the initial registration, and the optional survey, as well as all future

actions by the students (regardless of which LTI component they happen in) were recorded in the same data store (a PostgreSQL database), enabling us to make elements of our script conditional (e.g., on student progress or group affiliation), providing activities or materials according to features that emerge only during enactment of the script. On the EdX platform it is not possible do make access to one activity conditional upon the completion of another, but if students attempted to access any LTI component without having gone through the registration, they were asked to complete registration first.

The external server was hosted securely as part of University of Toronto infrastructure, and was written in Elixir using the Phoenix web framework. Elixir is built on top of the Erlang Virtual

Machine, which has a long heritage growing out of the telecom industry, and is characterized by supporting highly parallelized and distributed operation that is very fault-tolerant. This makes it highly appropriate for writing MOOC software, since the large number of potentially concurrent users requires a system that can easily scale up, and the rapid pace of development and live adjustments requires a fault-tolerant system that will continue running even if a single component becomes faulty.

The Phoenix web framework has built-in support for web sockets, a protocol for live two-way communication with web pages, which enabled us to prototype and build out live-updating components. Most of the web components were built using HTML and CSS, with minimal Javascript. However for the live-updating components we used the React web framework, which makes it easy to write rich, dynamic interfaces. Etherpad was hosted on the same server, and another server hosted the Confluence wiki system. The only fully external service used was Google Hangout for the video portion of the live events.