Stian Håklev

and 1 more

One of the initial promises of MOOCs was to enable learners from around the world to learn and build knowledge together. There is significant research showing that student collaboration can improve learning outcomes. Students are forced to externalize their ideas, working with multiple shared representations of knowledge structures, and collaborating to converge on a shared understanding of meaning. (Fischer & Mandl, 2005; Stahl, Koschmann, & Suthers, 2006). Globally distributed MOOCs bring in the added potential advantage of incredible student diversity, in terms of geographical location, life experience, culture and language. Ideally, we would treat the number of learners, and their diversity, as an incredible opportunity for rich learning and communal knowledge building, rather than as an obstacle to be overcome. Early work on MOOCs from Kotturi, Bernstein and Klemmer (2015) have shown that students learn more from geographically diverse discussion groups. However, several studies show that simply asking students to solve a task or discuss a problem is unlikely to engage them in a productive process of collaborative knowledge construction (Cohen, 1994; Mandl, Gruber, & Renkl, 1996). A key question, which has guided much of the research in the field of Learning Sciences, is how this process can best be supported and guided by an instructor or learning designer, as well as by the careful design of the physical and digital learning context and its affordances. Fischer and his colleagues (Kollar, Fischer, & Hesse, 2006; Fischer, Kollar, Stegmann, & Wecker, 2012) proposed a form of scaffold, which they call an “external collaboration script”, that specifies the roles and goals of the participants, allocates material and tasks, and coordinates student grouping and learning activities. This new way of conceptualizing a “script” became a more general means of referring to any designs that helped to guide students and teachers through prescribed forms of learning interaction (Dillenbourg & Jermann, 2007). Once scripts have been designed (Tchounikine (2008) presents a proposed design approach), they need to be implemented or enacted. Dillenbourg, Nussbaum, Dimitriadis, and Roschelle (2012) call this process “orchestration”, defined as “how a teacher manages, in real time, multi- layered activities in a multi-constraints context” (p. 1). CHALLENGE Despite a long history of research on pedagogical scripts for small groups and school classes, there have been very little research on appropriate pedagogical scripts that take advantage of very large numbers of heterogeneous learners. Håklev (2016) suggested some design principles for pedagogical scripts for MOOCs, with a matrix of weekly thematic scripts which feed into a set of interdependent longer running scripts. We need more creativity and sharing in this area, and to enable this, a common notation, or educational modeling language, as well as tools for editing and sharing educational scenarios, could help. However, our largest challenge is how to implement these scripts in very large settings. A school teacher can fall back to using sticky notes and “talk to your neighbour” strategies, but currently implementing even a trivially simple script in a MOOC which is not supported by the platform (even wanting to do peer-review, but in a different way than the built-in approach) requires significant software development resources not available to most groups. This paper will present a suggested common educational modeling language called Orchestration Graphs, our prototype framework for authoring and collaborating on Orchestration Graphs, as well as the design of an ecosystem of activities and operators which can be “run” by an Orchestration Engine. We posit that this is an innovation which has the potential to promote the development of richer collaborative activities at scale. ORCHESTRATION GRAPHS An Orchestration Graph is a structured view of a learning scenario, consisting of learning activities (nodes). These nodes have a start and an end-time. The X-axis of the graph denotes time, and the placement and width of activities denote start and duration. In short synchronous scripts, these time cut-offs might be absolute, to enable students to “sync up” (e.g., after five minutes, everyone has to switch groups), whereas in long-running asynchronous activities, activities might be open for several days, and students can choose when to visit them. Activities take place at different social planes (Y axis), the three key ones being individual activities, team-activities, and whole class activities. One can also add additional planes to include the community and the entire world outside of the specific course. Activities (nodes) are connected through edges. These can contain pedagogical justifications (e.g., activity 1 is an advanced organiser for activity 2), learning analytics information (e.g., student success is activity 1 is 34% correlated with/predictive of success in activity 2), and operators which transform student output, and generate social structures. Prior art The idea of a modelling language that visually expresses pedagogical design also has a long history with ‘Educational Modelling Languages’(EML). The best known EML is LEARNING DESIGN (IMS-LD3) a standardized specification of learning activities. However, it does not support rich collaborative scenarios, for instance with automatic group formation (Van Es & Koper, 2006). LAMS (McAndrew, et al, 2006) offers a graphical editor of templates based on IMS-LD and executes them. COLLAGE (Hernandez-Leo et al, 2006) proposes richer design patterns, which can be executed within GLU!-PS (Prieto et al, 2011). Two recent platforms, ILDE (Hernandez-Leo et al, 2014.) and LEARNING DESIGNER, inspired by Laurillard’s popular book (2013), builds upon a community of designers. The latter provides feedback to designers, for instance the proportion of various learning activity types (investigation, practice, etc.). However, the designed scenarios are not runnable on the platform. EXAMPLE Collaboration scripts (graphs) can describe tightly orchestrated live interactions, such as a “jigsaw script” centred around earthquake mitigation in San Francisco, where each team comprises 4 roles: the mayor of San Francisco (a2a), a seismology expert (a2b), a security o cer (a2c), and an insurance agent (a2d). Students begin by discussing the task in groups composed of all four roles, but are then interrupted by “expert group meetings”, where all mayors meet with each other separately. This cycle can be repeated several times, before the teams (a4), which are then aggregated by the teacher (a5).