[Brief] Modular Content Delivery - Platform Strategy
Goal of this document:
There are currently 8 proposals (linked below) in the product pipeline related to the concept of modular content sequencing and delivery. (From edly, Schema, edunext, OpenCraft, Unicon.) Each touches on various parts of the workflow, but no single proposal encompasses the entire workflow.
This document is intended to:
articulate a platform-level strategy under which we can align the proposals
get aligned on what general capabilities we need to build
identify any gaps
raise open questions around scope and implementation strategy
Strategic Platform Goal:
The Open edX platform needs a unified, generalized, flexible way for course teams, instructional designers and administrators to sequence, bundle and deliver learning pathways. The structure and content of these learning pathways may be varied, for example, a sequence of courses to create a program, or a sequence of lessons to create a competency, or a micro-credential or a non-credit pathway. What we need to build is the generalized feature set (or set of capabilities) that enables flexible pathways to be constructed, named, configured and delivered. (See below for possible MVP and phasing, under each major capability/feature.)
We need to consider each step of the learner and administrator workflows:
Admins/course teams need to create and configure the learning sequences, including the remix and reuse of content
Learning sequences need to be configurable for grading rubrics, pre-requisites, completion criteria, competency frameworks
Learners need to be able to find and enroll in learning sequences
Learners need to be able to track their progress through a sequence
Learners need to obtain a credential on completion of a sequence
This capability touches many parts of the platform, including:
Catalog (for searching and enrolling)
Studio and Libraries (for building the sequences)
Learner Dashboard and LMS (for tracking progress)
Credentials Service/Wallet
Value Proposition:
Each of the 8 proposals is grounded in user data and use cases that illustrate the growing market need and interest in more flexible approaches to learning, microcredentials and competency-aligned learning. Eg, Eg, Eg, Eg.
Generally, enabling organizations to define and customize the size and shape of their learning pathways, in alignment with their institutional goals and pedagogical outcomes, is a key part of the platform’s extensibility strategy.
Additionally, this will open the door for institutions to create and deliver microcredentials, non-credit pathways and competency-based pathways, all of which are foundational to upskilling and reskilling initiatives and workforce development.
General high-level capabilities/features
An interface for course teams and administrators to build, name, and configure the sequences.
Alignment from proposals:
Edly has proposed a sequencing feature which would allow teams to specify program types, sequence courses, configure completion conditions. No authoring takes place in this feature, only sequencing. Their designs are scoped to sequencing courses to create programs.
Schema has proposed a Grouping Product feature similar to Edly’s, that also includes the ability to sequence Library content.
Schema has also proposed a new content type, Learning Sequences, but there are questions to untangle here such as the difference between a Learning Sequence and stackable subsections or sections, for example.
OC has proposed a sequencing feature similar to Edly’s, which enables admins to choose courses to sequence and apply metadata and completion conditions.
Unicon has proposed a milestone that associates competencies to content sequences with assessment criteria
Examples of general requirements (not exhaustive):
Sequences can be defined and named/titled
Content in sequences can be ordered and re-ordered
Completion criteria can be specified and is flexible (ie, learner needs to complete 3 of 5 sequences, etc)
Sequences (and content within them) can be aligned to competency frameworks and assessment criteria
Designed for integration with credential wallets or LRS. Student state must be stored for new types of enrollable learning experiences as it is for courses today. Events should be available at expected points, for example, start, and completion.
Possible phasing:
MVP - Courses can be sequenced into programs
Phase 2 - Library content can be sequenced; more complex (and/or new?) sequence types
Phase 3 - Competency frameworks/rubrics can be aligned
**Note: Phase 2 will require specs for defining enrollment and completion criteria for content in libraries. Will require significant discovery.
Open question - is there a way to start delivering value from phase 3 earlier and more incrementally?
A discovery experience for learners to search for and enroll in sequences
Alignment from proposals:
Edly has proposed a discovery interface that will allow learners to browse all courses and all sequences in a unified display.
OC has proposed a similar discovery interface. They also propose a deeper integration of the discovery experience with the Learner Dashboard, so learners can see all the courses and sequences they are enrolled in + the courses and sequences they might be able to enroll in.
Examples of general requirements (not exhaustive):
Searching for courses and searching for sequences must be a unified experience for the learner
One-click enroll in sequences
Filter for courses and sequences
Easy views of all the content within a sequence
Easy views of completion criteria
Possible phasing:
Would need to be built/released at the same time as the sequencing MVP
A progress tracker so learners can track their progress through a sequence
Alignment from proposals:
OC has proposed a simple progress indicator that shows learners which courses in a sequence they have completed and which they have not yet completed, viewable from the Learner Dashboard
Unicon has proposed a robust progress tracker that lets learners see which competency pathway they are in, how much is left to complete, and what their progress is toward mastery of that competency
Examples of general requirements (not exhaustive):
At first glance, learners can easily see where they are in the sequence, what they have already accomplished, what they still need to accomplish
Learners can easily see the end-goal they are working toward
Possible phasing:
MVP - To align with the MVP of the course—>program sequencing, the MVP of the tracker would let learners track progress through a program
Phase 2 - TBD, would need to align with how the subsequent phases of the content sequencing tool evolve
Open Questions:
Are there more incremental ways we can deliver on the competency-based milestone or is it blocked on the prior two phases?
What role does Learning Core play in all this?
How does this change how we think about sequencing within courses? Does it?
Open questions around implementation of the catalog - see below
Implementation Details:
There is some divergence in implementation approaches to the catalog:
Edly has proposed building a catalog plugin that integrates with edx-platform, which includes a sequencing tool on the Studio side and a discovery tool on the learner side
Schema has proposed a catalog as a standalone service, designed around a set of core functionality for metadata capture, publishing catalog objects, handling bundles, rendering enrollment pages. Product features such as the sequencing tool would be built on top, either as core or plugins.
Edunext has proposed a catalog as a set of primitive APIs, on top of which all product features would be developed as plugins
Proposals Index:
Comments
Architectural Goal: Interoperability through shared primitives
While I support the effort to consolidate some of the work in flight from a product point of view, I also strongly suspect that people are going to want to do some radically different things when it comes to how Learning Pathways are authored and composed. From an architectural point of view, I’m wary of trying to design any broad framework that is capable of capturing the full breadth of use cases that I’ve read about.
Given that, I think that our architectural priority should be building out the primitive core pieces that will allow various plugins to interoperate with each other. Someone might have a plugin that introduces a new type of content module that is not a part of our normal Course → Section → Subsection → Unit hierarchy. A different plugin from a group working on continuing medical education may introduce a byzantine set of configuration options for how to compose Learning Pathways, taking into account the ever changing regulatory requirements introduced by various state medical boards.
On the dev side, our priority should be to make sure that when some medical school installs both of these plugins at the same time, they should work together seamlessly. The thing that composes the really complex pathways can operate on a new type of modular content because they only intersect each other in a set of core primitives that both plugins understand. The goal isn’t consolidation, but interoperability.
To give a more concrete example, there should be some core concept of a Pathway in our system. That Pathway has a relationship with a student for things like progress. Concepts like “this Pathway exists”, “this student has completed this Pathway”, and possibly “this Pathway has the following pieces of content associated with it” would be core data models.
On the other hand, the encoding for “this is a linear pathway where you must complete items 1, 2, and 3 in that order” is something that, from the technical side, lives in plugin code. (Note: This can be a bundled plugin that is part of the core product experience.) That way, the part of the system that reports on student pathway progress is decoupled from the dozen exotic pathway construction plugins.
The core models wouldn’t represent the default student experience. The core models would represent the absolute minimum data and interfaces that all plugins (including the default experience) need to agree on so that the various extensible subsystems can interoperate with each other:
Pathway sequencing (authoring and delivery): How we arrange different content for a student.
Pathway node execution (authoring and delivery): What kind of content is at a particular node of the path (e.g. course, diagnostic, LTI, section, etc.)
Pathway progress and completion.
Credentials for Pathway completion.
Tagging
I realize that it’s easier said than done, but I think this is extremely important. We don’t just want Open edX to be extensible in this regard, we want Open edX to be the obvious choice for building innovative learning experiences. That means that we are going to need to support a robust ecosystem of plugins that can be composed together to make drastic changes to the teaching and learning experience. I can’t wait.
Are courses the right starting place?
It seems like the proposals on the table largely focus on the composition of courses, which is pushing us to frame this in terms of a Catalog. But my understanding is that this is meant to eventually include content that is much more granular than a course, such as individual subsections, or even smaller.
From a product point of view, I can see how it makes sense to start with courses, given that it’s the thing we have. From the technical side, I worry that approaching it with this mindset will introduce unnecessary coupling to courses that will make it much more difficult to support more flexible content later on.
I’d like to see if we can frame Learning Pathways as a flexible composition of Learning Contexts, of which courses are one type. We can already store a lot of student state information against arbitrary Learning Contexts. We could imagine a world where yes, courses are Learning Contexts that can be composed in this way, but you can also create arbitrary Learning Contexts in a library (or define them as Collections in that library).
(Honestly, even casting it as Learning Contexts feels a little off from what the ideal is--it doesn’t completely capture the idea that some content experiences are basically equivalent, like two runs of the same course. But I think it’s a decent place to start and it’s easier to wrap our heads around.)
If we did adopt that approach, the question would be: What is the minimum set of data and relationships about a learning context (like course) that we would need in order to make a pathway? It seems like we’d want at least:
Student state storage for content (e.g. what is their answer for this problem).
Progress and completion information, in both detail and summarized forms.
The ability to associate tagging data.
Access control (but not necessarily enrollment)
This smaller subset of data could be something that goes in Learning Core and that existing courses know how to use and reference. It would potentially open up a lot of longer term flexibility if people writing extensions could make any given thing a part of the Learning Pathway as long as their plugin could fill in those few criteria. With a data model like this, I could even see someone making an external LTI resource be part of a Learning Pathway.
Note: I do think the idea of a Catalog is important. I’m just not sure if it’s really the first primitive piece we need to build out for this to work.