Traditional Learning Management Systems (LMS) such as Blackboard, as well as new MOOC platforms, such as EdX, offer ways of distributing content, and certain built-in tools for student engagement (such as quizzes, discussion forums, or peer grading). However, these platforms usually do not offer any support for implementing pedagogical scripts, and the collaborative tools are usually inferior versions of single-purpose Web 2.0 tools that exist outside of the platforms.
There are many free-standing Web 2.0 tools that offer innovative ways of creating and
collaborating online, from communication tools (chat, voice and video), to collaborative creation tools, including text editors, brainstorming and collaborative mindmapping tools, drawing pads, 3D modeling applications and more. Only a few of these tools are open source and can be hosted locally (like the collaborative editor Etherpad), and most tools have no possibility of single-sign on, or APIs that allow implementing a pedagogical script.
To integrate these tools into our workflow, we would want to enable single-sign on (students can access tools through a link in their LMS and are automatically logged in with their user id) and group awareness (e.g., a Google Doc is automatically shared between the members of a pre- existing MOOC group). We would want to scaffold (automatically insert a template before users
begin to edit), and exchange artefacts (take a Google Doc from one group and send it to another group, or extract the text and insert it into another tool, such as a wiki).
In the Pre-Service Course, we used Confluence wiki (which is not open source, but hosted locally, and has a rich API for automatically managing content and users), together with Etherpad (open source, also hosted locally, and with a rich API). We also used a number of custom-written Python scripts to automate the creation of users and groups, insertion of wiki templates, and movement of content between the Etherpad and the wiki, and between different wiki pages. These scripts were all manually triggered, and applied a certain action to the entire class (add a certain page to every student's homepage for example).
Some MOOC teams have used the single-sign on functionality to connect an external platform to their course on EdX or Coursera. For example, the Learning Analytics DALMOOC (Ferschke, Howley, Tomar, Yang, & Rosé, 2015) developed an external social platform called ProSolo, which could be accessed through a link in their EdX course. However, students clicking on this link would "leave" EdX and "enter" ProSolo—a completely separate site, with it's own menu structure and navigational hierarchy. This movement between separate platforms can be confusing to students, who often struggle in any case to understand how they are supposed to engage with course software, materials, peers and instructors.
In our MOOC, we built a server that maintained a student model for each student including demographic data, group memberships, past activities as well as interests and relationships. This served a number of different pages/components, which were embedded at different points in the EdX timeline. Although each component seemed like it was completely separate, they all relied on the same underlying database, and were driven by a unified algorithmic logic embodying the pedagogical scripts. A simple example is conditional access, in which a student could not access a certain component y unless he or she had already completed a previous specified component x. This was not possible to do in EdX alone. More complex examples include the transferring of content generated in one component into another component, enabling personalized e-mails, etc. We embedded two external tools, Etherpad and Confluence wiki into our LTI frames. Using the same APIs as in the Pre-Service Course, we were able to embed these two tools seamlessly into the workflow. For example, we automatically created wiki accounts for students registered with the external server, and when they accessed the collaborative workbench, we automatically
logged the student into the wiki, and embedded a view of the appropriate wiki page, depending on their group membership. Having access to all student data, including content generated, group memberships, and activity records, made it possible to generate a comprehensive learning
analytics dashboard, where each individual data point linked directly to the artefacts described, and where administrators could quickly enter individual student group spaces as "visitors".
6.5 Future research directions
The growth of online learning in higher education, and the emergence of MOOCs, offer exciting new research opportunities for the Learning Sciences community. To make a successful
contribution to learning at scale, our community must offer not only theoretical advances, but also applied research to overcome the technological challenges of scripting and orchestrating large numbers of students in fully online and hybrid settings, enabling the development of rich collaborative scripts where students are able to effectively build knowledge together in small groups, and at the same time benefit from the diversity and inspiration from the larger course community.
In our first Key Design Challenge, we looked at how to design a meaningful hierarchy of groups coherent with the semantic and social requirements of the course scripts, and support their collaborative work. More empirical studies are needed to determine the ideal relationships between group attributes (size, group formation approach, diversity among different dimensions) and types of collaborative tasks. Student models are crucial in supporting purposeful group formation, and could be extended through richer student profiles that persist beyond the duration of a single course, indeed groups could also persist across courses. Finally, the design of online tools to support group collaboration could implement more of the research on micro-scripting group interactions, with students being assigned roles and automated prompts based on machine- learning models of group progress (which could also be made visible to students through group awareness displays).
In our second Key Design Challenge, we wanted to enable a flow of ideas and artefacts across groups, and not just down through a hierarchy of nested groups. In the MOOC, we collected a large amount of semantic tags describing users, and resources, but due to engineering challenges, these were used only to a limited extent. Future courses could use semantic data, both explicitly entered as tags and categories, and implicitly extracted through semantic text analysis, automatic
image recognition and other tools, to match students to other students, or students/groups to artefacts across group hierarchies. The extent to which this kind of intelligent mapping can replace some of the group hierarchy for the purposes of maximizing homogeneity or diversity, and reducing information overload for students, is an interesting question to explore.
In both the Pre-Service Course and the MOOC, we used technology to support the orchestration of complex scripts, and interdependencies between scripts. In both cases, this required the development of a large amount of custom code. In the Pre-Service Course, we used Python scripts and Application Programming Interfaces (APIs) to integrate a number of different Web 2.0 services, and automate the creation of templates, movement of artefacts, etc. In the MOOC, we custom-built a server for all of our interactive features based on a persistent student model, which was integrated with EdX using the LTI protocol. Most research projects, let alone individual teachers wanting to experiment, cannot afford this amount of technical work to implement a project. How to enable easy instantiation of instructional designs and scripts on technological platforms is an open research question. On one end of the spectrum, we could imagine developing a protocol like LTI which enabled richer linkages between applications, enabling for example the exchange of student artefacts. On the other end, one could imagine embedding more supports for scripting group work directly into MOOC platforms.
In our third Key Design Challenge, we focused on facilitating collaborative work in an online setting. Above, I addressed the need for better collaboration and communication for small groups, use of semantic tags to create connections, and supporting easier instantiation of designs by researchers and instructors. Another aspect worth exploring is better support for rich
synchronous meetings. Currently, almost all the interactions in MOOCs are asynchronous (you can log on when you want, and you will see what other people have done while you were away), but synchronous meetings offer important opportunities in terms of motivation, sense of
community, and the opportunity to enact dense collaboration scripts that would be difficult in an asynchronous setting, due to the turn-taking effect.
An instructor in a physical classroom with a small group of students might switch between a number of different activities and configurations during a class, jumping effortlessly from talking to the whole class, having students discuss with their partner, and then they might join into table groups and work on a project, while the instructor is circulating and offering suggestions.
However, the default for online synchronous meetings seems to be to meet as a whole group in a Google Hangout or similar tool to have a discussion. There is a need for better tools that enable instructors to transition between many different group configurations dynamically, and integrate rich live-collaborative tools to do real work together. The large numbers of online students also offer new possibilities, such as ad-hoc synchronicity, where students can have the option of engaging another student who just happens to be online at the same moment, working on the same problem, without having to be online at a pre-scheduled time.
Finally, the scope of the two design studies in this research project has been the length of a single course. On-campus learning management systems have been criticized for lasting only for the duration of a semester, with students losing access to their own work after the course has ended, and each new generation beginning with a blank slate. This practice has continued in the design of MOOC platforms, where all social interactions are confined to a single course, and instructors do not have access to any information about student performance or ideas generated from
previous or other courses, and students have no way of creating lasting social bonds that transcend individual course communities.
A small attempt to overcome this has been our focus on connecting course generations through the sharing of student artefacts. However, a fruitful line of inquiry would be to look at enabling students to establish social profiles and connections that last through many of their courses (and ideally across different platforms and mediums of learning). Rather than examining what the students have gained in the six weeks that a given course lasted, we could look more deeply into how that course fit into a students’ learning and professional trajectory. Six months after the course has ended, is the student incorporating ideas from the course in their professional practice (perhaps even adapting the lesson design they worked in the course)? Is the student still in touch with other students from the course?