In Part 1 of this series, we discussed possible mental models that could be used to enhance or replace the current lesson navigation component in LifterLMS.
In Part 2, we went a step ahead and planned the markup and the copy that would be involved in implementing such revisions.
This concluding part discusses the actual code needed to implement the ideas discussed in the earlier parts.
In Part 1 of this recipe, we explored various UX patterns for Course Navigation where one of the central theme was that the Mark Complete (or similar) and Next Lesson actions are subtypes of the same Next Step action in a basic intuitive course model.
For the UI, this means that the Mark Complete button and the Next Lesson button become citizens of the same visual space – the right column (next step) of a two column navigation.
For that to happen, we need to change the markup of the navigation component in the template system.
Default Navigation Templates
The two templates responsible for the two distinct experiences are:
This lesson-preview.php template is also used within the Syllabus component. So, we’ll also need to differentiate between the use of this template in these two contexts, either by splitting it into two separate templates or by modifying the output for each context.
Which means that whatever the final pattern we build, we’ll have to redo the templates. What we’re looking for is a two-column layout where the left column will always contain only one action but the right column may contain more than one actions.
If you spend some time going through the code in the templates above, you’ll notice that the current markup is structured like this:
In this markup, like we’ve discussed in the earlier part, the task completion model and the navigation model have two distinct spaces. What we want to do instead is to rearrange them into a structure similar to this:
We’ve divided the navigation using two new top-level div’s while moving the existing navigation elements a level deeper. In the div for the next action, we’re attempting to differentiate between the primary and secondary actions. This will help us prioritise the primary action visually, irrespective of its order in markup.
At the same time, we don’t want to modify the selectors so that any existing functionality doesn’t break and we achieve what we need with minimum code.
Various States of the Navigation UX
Before going further, let’s take the various permutations in stock. I have listed five states of the navigation
Standard Lesson not yet completed.
with a regular Mark Complete button
with a Take Quiz/Start Assignment button
Completed Lesson.
with a Mark Incomplete button
Next Lesson is Restricted (via prerequisite/drip)
First Lesson (No Previous Lesson, so replaced by Back to Course link)
Last Lesson (No Next Lesson, so replaced by Back to Course link)
We’re considering all the variables in this part of the tutorial. In a subsequent part, we’ll look at special cases where some of these variations will either not exist (for eg, Mark Incomplete) or will be implemented differently.
It is also important to note that at this stage, the Take Quiz and the Start Assignment buttons can be considered as the same UI component as the Mark Complete button.
Also, this doesn’t claim to be exhaustive and cover every possibility, just most of them. Even the copy is something you can obviously modify. (If you do see something missing, let us know in the comments and we’ll try and update this series accordingly!)
So, we’re going to change the text of the buttons a bit for explicit choice and an interactive human voice.
State 1. Standard Lesson
In situation 1, for example, we could use:
Primary Action: Mark Complete & Go to Next Lesson
Secondary Action: Next Lesson without completing
State 2. Completed Lesson
Once the lesson is complete (situation 2), we could use:
Primary Action: Go to Next Lesson.
Secondary Action: Mark Incomplete.
At this point, it is useful to note that, the text Lesson Complete is displayed in place of the Mark Complete button irrespective of whether marking incomplete is enabled. When Mark Incomplete is enabled, there is a button as well as this text.
In another recipe, we’ve discussed ways to move this indicator and make it more obvious. This way, the Lesson Complete text becomes redundant. One less element to worry about in our navigation.
Now that that’s out of our way, let’s try rewording the options for a lesson with a Quiz:
Primary Action: Take Quiz to Complete Lesson.
Secondary Action: Next Lesson without completing.
For a lesson with an Assignment:
Primary Action: Start Assignment to Complete Lesson.
Secondary Action: Next Lesson without completing.
State 3. Restricted Next Lesson
When the next lesson is restricted because of a prerequisite:
Primary Action: Mark Complete & Go to Next Lesson.
Secondary Action (disabled): Next Lesson unavailable before completing {lesson link}.
The primary action may not lead the user to the Next Lesson if it’s prerequisite is a completely different lesson. So, we need to differentiate between scenarios where the current lesson is a prerequisite of the next lesson and where another lesson is a prerequisite instead.
In the former, the copy can stay as it is. In case of the latter, the primary action can’t say Go to Next Lesson, it’d have to just say Mark Complete.
When the next lesson is restricted because of a drip:
Primary Action: Mark Complete & Go to Next Lesson.
Secondary Action: Next Lesson unavailable before {date}.
State 4. First Lesson
On the Last Lesson:
Primary Action: Complete and go back to Course.
Secondary Action: none.
On the First Lesson, nothing changes with respect to the next step. Only the Previous Step is a little different.
State 5. Last Lesson
To summarise, here are all the variations we’ve discussed, placed together for clarity and context:
Default
Primary Action: Mark Complete & Go to Next Lesson
Secondary Action: Next Lesson without completing
Completed
Primary Action: Go to Next Lesson.
Secondary Action: Mark Incomplete.
With Quiz
Primary Action: Take Quiz to Complete Lesson.
Secondary Action: Next Lesson without completing.
With Assignment
Primary Action: Start Assignment to Complete Lesson.
Secondary Action: Next Lesson without completing.
Prerequisite
Primary Action: Mark Complete & Go to Next Lesson.
Secondary Action (disabled): Next Lesson unavailable before completing {lesson link}.
Drip
Primary Action: Mark Complete & Go to Next Lesson.
Secondary Action: Next Lesson unavailable before {date}.
Last Lesson
Primary Action: Mark Complete & Go Back to Course
Secondary Action: NA
Now, that we have almost all the pieces in place, we can start building this navigation.
Next Step Amalgam
Contextual States
Visual Hierarchy
Depending on what model you prefer, you could easily use a bit of CSS to achieve any of these with the same markup guidelines shared at the start.
If you’re a developer, this should be enough to get you started on the code modifications needed to implement these. If you are planning to do so or have already implemented this, share your results with us in the comments.
If you’re looking for copyable code that you’d like to repurpose, part 3 is underway.
Wistia: Add option to enable/disable the video player’s “playbar” (progress bar, scrubbing, and timestamp review).
Bug Fixes
Fix issue causing the lesson progression button from being disabled for videos that don’t explicitly have video completion progression requirements enabled.
Wistia: Ensure that all oEmbed fetches always fetch the supported iframe embed type.
Wistia: Automatically remove videoFoam from embeds.
Wistia: Set default theme color option value to match the documented default theme color.
Add filter: llms_user_caps_edit_others_posts_post_types to allow 3rd parties to utilize core methods for determining if a user can manage another users LMS content on the admin panel.
