As awesome as this project is, there were a number of challenges I needed solve before adopting it for Mozilla’s Community Education Platform:

Hierarchy

Jekyll is a blog-aware, static site generator. It uses template and layout files + markdown + CSS to display posts. Course in a Box comes with a top level category for content called modules, and within those modules are the content – which works beautifully for single-course purpose

The challenge is , that we need to write education and training materials on a regular basis, and creating multiple Course in a Box(es) would be a maintenance nightmare. What I really needed was a way to build multiple courses under one or more topics vrs the ‘one course’ model. To do that, we needed to build out a hierarchy of content.

What I did

Visualized the menu moving from a list of course modules

To a list of course topics.

So Marketpulse, DevRel (for example) are course topics. Topics are followed by courses, which then contain modules.

On the technical side, I added a new variable called submodules to the courses.yml data file.

Submodules are prefixed with the topic they belong ‘under’, for example: reps_mentor_training is a module in the topic reps. This is also how module folders are named:

Using this method of prefixing modules with topics, it was super-simple to create a dropdown menu.

As far as Jekyll is concerned, these are all still ‘modules’, which means that even top level topics can have content associated. This works great for a ‘landing page’ type of introduction to a topic.

Curriculum Modularity

As mentioned, Jekyll is a blogging platform, so there’s no depth or usability designed into content architecture, and this is a problem with our goal of writing modular curriculum. I wanted to make it possible to reuse curriculum across not only our instance of Course in a Box, but other instances across Mozilla well.

The only drawback is that Jekyll expects all content referenced with include() to be in a specific folder – and so having content in with design files is – gah! But I can live with it.

And of course we can do this for multiple repositories if we need. By using a submodule we can stick to certain versions/releases of curriculum if needed. Additionally, this makes it easier for contributors to focus on ‘just the content’ (and not get lost in Jeykll code) when they are forking and helping improve curriculum.

Finally

I’m thinking about bigger picture of curriculum-sharing, in large part thanks to conversations with the amazing Laura Hilliger about how we can both share and remix curriculum accross more than one instance of Course in a Box. The challenge is with remixed curriculum, which is essentially a new version – and whether it should ‘ live’ in a difference place than the original repository fork.

My current thinking is that each Course in a Box Instance should have it’s own curriculum repository, included as a git submodule AND other submodules needed, but not unique to the platform. This repo will contain all curriculum unique to that instance, including remixed versions of content from other repositories. (IMHO) Remixed content should not live in the original fork, ans you risk becoming increasing out of sync with the original.

So that’s where I am right now, welcoming feedback & suggestions on our Mozilla Community Education platform (with gratitude to P2PU for making it possible)