Working with a world class information architect is a treat and has helped steer our thinking about how we structure educational content for the past three years. It's been a challenge to migrate. These core data decisions have a way of locking you into previous, sometimes poor, decisions. We did an engagement with Lisa Maria Marquis, author of Everyday Information Architecture, and LMM looked at our lessons, courses, playlists, series, and other media and came back with a simpler, straight forward way to think about them.
Early on we were overly specific at the database level and described database tables as they were used or labeled in the user interface (UI). In retrospect, starting from more generic building blocks and working towards more specificity would have been a better approach for us, and thinking about structured content as data instead of UI makes a lot sense in practice.
There were a lot of take-aways from LMM's awesome presentation, but the main one was...
#Everything is a resource
Some resources are a collection of other resources.
It's either a Resource or it's a Collection of resources.
LMM included "special" which in practice turns out to be a collection as well, which led us to solidify our own implementation.
#Naming is hard
Resource: a video, article text, file, or other atom
Lesson: a collection of learning resources
Section: a collection of lessons, and sometimes additional resources
Module: a full workshop, typically a 1-day workshop or shorter presenting a collection of sections or lessons (if sections aren't needed) and often additional supplementary resources
Product: one or module modules in a collection
The atomic Resource is generally a direct reference to media. A resource is an interface or base type for specific kinds of resources. All resources share common properties such as id, title, description, and type.
In our domain, with use a VideoResource. This type of resources also has mediaUrl, transcript, and subtitles properties. Additional metadata that describes or belongs to this type of resource.
These atomic resources can be combined into a variety of collections. It makes things easier for us to think about if we give the collections names and use those to build consumable structures.
At the lowest level we have the Lesson which is a collection of resources that delivers a unit of learning. This is similar to building a page in Notion or other type of block editor. Stack, structure, move stuff around, edit, and present something that is coherent and meets the learning goals of the lesson.
It's great when a lesson stands alone, but they are often combined together into a Module. A module is like the chapter of a book, and might also contain other atomic resources like a project, overview video, or other supplementary/complementary resources.
If there are a lot of lessons, they might be divided into Section collections. Instead of directly adding lessons to the module, the lessons first get added to sections, which are then added to the module.
This is "chunking" and helps orient and provide structure for learners.
Finally modules, lessons, and other resources are combined into a Product which includes a price and can be purchased or shared with learners as a full learning experience.
#Implementation in Sanity
The tool that we love to use to implement structured content is Sanity. It provides a delightful environment to design your content model and query it through a fast CDN for delivery to learners.
We aren't inhibited by an overly specified content model and can think and rethink what the shape of a lesson or module is based on the content, the instructor, and what the students expect in the context of the domain being taught and not the domain we used to store shit in a database.
It's great.
