Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Flesh out the design

...

Rationale: Separating the outline from any XBlock runtime allows for much more efficient understanding and querying of the course outline, and provides better separation of concerns. Applying transformations to the outline (add/remove sections for certain users/runs only, shuffle them around adaptively, etc.) becomes much easier. The system can also support new types of micro learning experiences where, for example, the "course outline" consists of a single unit that is meant to be embedded into a blog post or another course. Finally, this design will explicitly disallow units that have multiple parents, which causes some issues in the current LMS.

Transforms

...

apply -izations

Building on the success of the "block transformers" in the current LMS, all learnable content will go through two distinct "transforms" which will each apply customizations and optimizations to the learnable content.

...

While the compiled course which is output from Transform 1 can be cached until a change to the course is published, Transform 2 will be a more real-time transformation which applies user-specific changes to the compiled course. This may include checking user permissions and modifying the course accordingly, applying individual due dates, loading and assigning randomized content from a compiled content library, showing/hiding content based on content groups / cohorts, and even modifying content visibility based on the recommendations of an adaptive learning engine. The output of Transform 2 will be in the same format as the output of Transform 1.

The XBlock Runtime is isolated

The XBlock runtime will be modified to work when the course/section/subsections are no longer XBlocks, so the root of any given XBlock tree that it loads is always a "Unit".

The XBlock runtime and the LMS will save state (XBlock scope.user_state fields, ORA2 data, grades, and completion) into the "learning record store" which will be grouped by "learning context ID" instead of course ID. This enables XBlock Units to be used outside of course contexts (e.g. in blog posts or microcourses) while still being able to take advantage of all the LMS features. This also provides a straightforward migration path for the existing codebase, because any "course ID" currently used in the system can double as a "learning context ID".

In the long term, the goal will be to move the XBlock runtime into a separate process, so it no longer runs as part of the LMS process.