Discussion and Conclusion
6.3 Design principles at scale
6.3.3 Facilitating Online Collaborative Learning
6.3.3.3 Scripting with open movement
A traditional approach to scripting assumes that the instructor is able to move the class through a number of pre-defined tasks and activities in unison. A classical problem-based learning script represented with Dillenbourg’s (2015) orchestration graph might describe how the class will first receive an introduction, distribute into groups, conduct individual research or reflection, then solve the problem in a group, and debrief in a large lecture (see Figure 45).
Figure 45 - Example of orchestration graph
From Orchestration Graphs by Pierre Dillenbourg, Lausanne: EPFL Press. Copyright 2015 by Pierre Dillenbourg. Reprinted with permission.
As a graph, the nodes (activities) are connected through edges (the lines between them), and edges can have a weight, which indicates how strongly they are connected. According to
Dillenbourg (2015), the strength of the connection indicates how strongly a subsequent activity is dependent on a prior activity. This dependency could be logistic (a subsequent activity depends
on an artefact, a grouping assignment or other produced by a previous activity) or
cognitive/emotional (a previous activity motivates/prepares students for a subsequent activity). In the example in Figure 45, the introduction (A1) is useful to motivate the students, but might not be crucial. Thus, the teacher could decide to skip A1 and jump straight to A2 for the entire class. In contrast, without distributing the students in A2, they would not know what problem they were trying to solve in A3. Thus moving directly to A3 would be counter-productive, even in a situation of limited time.
In a MOOC or other asynchronous platform, students have a certain measure of choice as to which activities to engage with, at what time, and in what order. The next two sections will examine these orchestrational decisions from the perspective of the instructor who is orchestrating the class, and from the perspective of the individual student.
6.3.3.3.1 Instructor/orchestrational perspective
To design robust scripts for MOOCs, we might reimagine the strength of an edge between two activities as denoting the importance of a certain percentage of the class having finished A before we release or open activity B. In the excerpt from a script shown in Figure 46, students are first asked to brainstorm resources (Activity A), and then in a subsequent activity (B), to look at the resources suggested by their peers, and add tags and reviews to them.
Figure 46 - Example of flow between activities
We can analyze the strength of the connection between A and B (the Edge) from two different perspectives. The first is the probability of success from a community perspective. In this case, in order for activity B to be successful, a certain percentage of students should have completed activity A before B (remembering that EdX cannot prevent students from just jumping to B even if they didn’t do A). If the assignment of resources to review in B is more sophisticated, for example requiring matching on student characteristics and semantic tags, we would want a large
proportion of students to have already completed activity A, to generate a much larger corpus of tags that can be matched to students in activity B.
A second question is whether it is useful pedagogically for students to still do A if they arrive too late (perhaps nobody will be around to review their resource), or to skip directly to B without doing A (they will still be able to review, but will miss the learning opportunity of entering their own resources).
Above, we have assumed that this script concerned the entire class, but we could also imagine that the granularity level of the sequence was lowered, perhaps taking place within each SIG, or at the design group level, requiring only the members of any group to be "in sync". Or perhaps scripts could be redesigned to be more flexible and resilient, for example by employing
personalized e-mail messages, where instead of the entire class moving from activity A to activity B, a student could receive an e-mail stating “some new resources relevant to you have just been added, do you want to rate them?”.
This points to an important issue of dissociating the scripting constraints from the platform that supports those scripts. If we hand-built our own MOOC platform (which in much of our case, we did—i.e., for all the LTI elements) we could enforce or enable a much wider range of scripting moves than if we use the existing functionality of EdX or some other MOOC platform. In any case, it is important for the instructor to be aware of the serial dependencies of any sequence of activities, and for the technological environment to support the instructors’ decisions or
commitments.
6.3.3.3.2 Student perspective
To understand how to design and orchestrate scripts in contexts with "open movement" as described above, it is important to conceptualize student activity choice. Students in MOOC platforms constantly make choices about their activities. They decide on when and how often to log into the course, which might be structured largely by external factors like job and family, but can also be triggered by things like e-mail notifications and reminders.
The large drop-out rates characterized by most MOOCs are manifested by students one day simply no longer logging into the course. So, understanding why this happens, and finding ways to encourage them to continue logging in, is reasonable strategy for lowering the high attrition
rate. In the discussion around synchronous and asynchronous events in Section 5.1.3, we discussed the difference between adding something to a calendar, versus adding it to a To Do list. For students in conventional courses where there is a set weekly class meeting, the default expectation is that they will attend at a certain time and date. However, with an asynchronous course where students are expected only to log in periodically (e.g., at least once a week), then attendance can simply be postponed, to the extent that the student ends up not coming back to the course, without ever taking a conscious decision to leave the course.
Once the student has entered the course platform, he/she has to decide which activity to begin, then after completing any activity, whether to continue or log off, and where to go next.
Activities vary greatly in their granularity, and thus the frequency by which the student is given this explicit choice. A small activity might be a short video, a quiz, posting a discussion forum post, or reading a short text. A non-bounded activity such as “working on a lesson design” does not have as many obvious decision-points, leaving the student to continually evaluate whether to keep working or to leave. And of course there are a number of micro-choices the student must make about how to organize his/her work within this larger activity.
A number of factors can influence which activity a student chooses next, many of which are under the influence of the course instructor and designer (see Figure 47). The course design itself, organized around weeks and chapters, and importantly with specific deadlines and grading structures (you only get a grade if you complete a certain unit before a certain time) is one factor. This course design is often instantiated in the website user interface, which might have a
hierarchy of menu bars, ribbons and activity sequences.
These vary drastically between different MOOC platforms. For example, Coursera has a list of weeks in the sidebar, and for each week there is a single linear flow of sequences on a long scrolling page, mixing videos, text and quizzes, whereas assignments are found on a completely different tab. EdX, on the other hand, provides the same list of headers (e.g., for each week) on the left, but these are then expanded into a list of sub-activities, containing a variety of content types (including assignments). The list of activities might induce students to jump around within a week, whereas the existence of course assignments within the activity sequence might
Figure 47 - Factors influencing choice of movement within MOOC activities
The order suggested by the course interface can be enforced through code, by making access to certain activities conditional upon the completion of previous activities (“unlocking”), or by enforcing a direct move into activity B directly upon the conclusion of activity A. The interface can also conditionally show different activities and materials depending on the user profile stored in the database, for adaptive teaching and research purposes. In traditional MOOC platforms, the only functionality of this kind is timed release, where a given material or activity can be locked until a certain time. However once it appears, it is available to all students. The external LTI server used in INQ101x introduced the possibility of conditional access, which we used, for example, to limit access to any LTI resources for students that had not already registered their
profile, or access to the Collaborative workbench for students who were not part of a design group.
Apart from the passive design of the user interface, which might include written exhortations (or video instructions) such as “when you have completed this segment, please go to this other activity”, courses could also feature interventions such as pop-up prompts, e-mails, messages or reminders sent to students asking them to visit a certain activity at a certain time. These could be automatically dispatched by the system based on some logic, or individually triggered by the teacher (weekly e-mails are one form of this). The instructor emailing all students saying “We have now completed 500 resources, and we would like to invite you to vote on your favourite ones” is the equivalent of the instructor in a classroom asking teams to move on to the next activity.