Skilljar Structuring and Scheduling Content
- Matthew Harrington
Structuring Content
Skilljar content follows a simple, linear hierarchy of the following structural elements:
Courses - are courses. They contain everything, as well as the associated learner enrollments and other data.
Lessons - are pages of content.
Sections - are purely structural elements designed to group lessons together
Sections are not required for content, unlike Open edX, they are simply used for content organisation.
The only settings available for sections is what the section is called, and whether to display a short description for the section in the outline.
Curriculum - is the term given to all content within the course, both at the course level and the section level.
A course contains a curriculum that consists of lessons and sections, and each section has a curriculum that consists of lessons.
Shaping Content
The way lessons are created actively shapes them towards being focused on a single or primary element, such as a video. They do this by making you pick a content type when you create a lesson:
When you select a lesson type (the lesson types shown above being Video, HTML, Quiz, Live Training, SCORM/Web Package, Files or Web Content, Audio, or LTI 1.1 Lesson), it creates a lesson with that content type being added.
What’s interesting about this is that Skilljar actually functions similarly to Open edX. Lessons can have multiple different content types, which can be stacked in a single-column layout. They just
In addition to this (I know this is getting into content structure, but there’s really not much more to talk about with Skilljar’s structure), they have additional restrictions on content to enforce best practice for their platform, as listed in their documentation:
You can add up to 15 pieces of content to a lesson, although we recommend adding no more than six per lesson to ensure the most seamless learning experience.
Only one quiz can be used per lesson.
iFrame is only compatible with the files/web content lesson type.
As far as I can tell, there’s very little practical reason for these restrictions other than because they’ll make the course look and perform badly (though quizzes are likely a more technical limitation).
Each lesson includes a summary element, which is an HTML element that is intended for summarising the contents of the lesson. This is once again a content-shaping feature, as essentially there is no difference between doing this and including a regular HTML element to summarise the lesson. It purely exists to ensure non-learning professionals (Skilljar’s target audience) implement best practices in their course materials and summarise what they’ve just taught learners.
Scheduling and Releasing Content
Unlike other platforms, Skilljar does not care about dates by default. There is no start date, no end date, or any of the associated features. The course is either published to the course catalogue, or it is not.
Course enrollments can be closed at any time without removing access to the course. If instructors want to set a course expiration date (locking out learner access), or set a due date for completing the course (not individual assignments, the entire course), they can do so from the course settings:
These are blank by default, and intended for a very different use case from traditional instructor-paced LMSes. For example, in an instructor-paced course, expiration (or end) dates would typically be defined to reflect course support and staff availability. On Skilljar, this option exists because organisations are commonly given “training credits”, which are spent to access courses, effectively meaning companies and individuals can be charged for 30 days of course access or similar, enabling their ecommerce model.
As you’ve probably noticed, those dates are also entirely tied to the learner’s enrollment date. Relative due dates are an alternative, experimental feature to most traditional LMSes, but for Skilljar they are the default, and only, tool for time-bound content, reflecting their focus on self-paced training.
Content within courses cannot be time-gated, but it can be gated by prerequisites that require grades or completion status for prior lessons.
Important Lessons from Skilljar
Skilljar are completely focused on the self-paced customer training use case. This shows in how little they care about incremental release dates - if the course is released, it’s released. This means that it’s probably safe to consider any features related to phased releases and scheduling as being entirely targeted at instructor-led courses, and should be tailored entirely to that use case. Restricting them to that use case isn’t a good idea, but any expansion of the functionality should consider the needs of synchronous courses as their top priority.
Skilljar deliberately channels their users towards creating courses that have lessons consisting entirely of single content types. This is effectively the exact opposite of Open edX, whose structure promotes creating blended content. They don’t prevent authors from creating blended content, but by selecting a lesson type (which is effectively meaningless in most cases, it doesn’t change anything other than the default content of the lesson), they effectively tell newer authors to focus their lesson on an asset without directly teaching it to them. Similarly by including a summary, authors are taught to summarise what they’ve just taught, which is a basic best practice. They do this because their users are typically not academic learning professionals or learning designers - instead they are developer advocates, content marketers, customer success managers, and similar customer-facing departments.
The lesson there is that we need to consider strongly how the user experience of tools can influence how content is built. Open edX provides a range of options at the bottom, inviting users to create course content that mixes and matches component types. The order of the different component buttons matter, the prominence of where components can be found will naturally influence how much different components are used. Buttons in the component tray should never be moved to the top “green button” level simply to make it quicker to access specific components, unless our intent is to drive users towards using those components.
An example of this is ORA and drag and drop, which aren’t relevant to all courses, but were moved to the tray in recent versions, in what I believe to be a slightly questionable move designed purely to solve the issue of them being stuck in “advanced”:
UI and UX shapes course design, for better, or for worse. Ensuring we have a clear shared understanding of what Open edX courses are intended to be, and how content should be shaped, is vital for future developments of Studio.