Enable finer-grained control over progress page components

[xitij2000]

Abstract

It is currently possible to show or hide the "Course Completion" widget on the progress page/tab for a course. We propose to make it possible to further customise this page by making it possible to also hide the Related Links, Course Certificate, Grades, Grade summary, and Detailed grades sections of the page.

Detailed Product Proposal

No response

Context & Background (in brief, if a Product Proposal is linked above)

This is a requirement that was brought to us by a client, and we've used the opportunity to add plugin slots to that page to allow implementing this for this client without modifying the default experience, however, if there is a broader need for this we can upstream the ability to toggle these components (in addition to the slots).

Scope & Approach (in brief, if a Product Proposal is linked above)

The work will involve three parts:

• Backend support for storing these toggles. Currently, there is a course field called disable_progress_graph that can be used to disable the course graph. Instead of adding a new boolean for each component we'll add a single dictionary field to store the status of different components in the progress page allowing future expansion. This field will be exposed via the requisite APIs to allow usage in the learning MFE.
• Additional UI in the authoring MFE to allow togging these new components.
• Updates to learner page to allow use the API status to show or hide those components.
  The primary beneficiaries are course authors who would like more control over the learner course experience.

Value & Impact (in brief, if a Product Proposal is linked above)

This proposal will make the default experience more customisable for course authors.

Milestones and/or Epics

This is a relatively straightforward proposal that can be implemented in a single sprint with the three tasks as broken down above.

Named Release

Teak

Timeline (in brief, if a Product Proposal is linked above)

If this proposal is accepted this work can be completed in a 2-week sprint starting after the approval.

Proposed By

OpenCraft

Additional Info

Progress tab config page with additional proposed options	Progress tab in course with each component labelled

[github-actions]

Thanks for your submission, @openedx/openedx-product-managers will review shortly.

[cassiezamparini]

@xitij2000 It would be helpful to see screenshots of what you're proposing (UI changes). Could you include these before I ask for reviewers?

[xitij2000]

@xitij2000 It would be helpful to see screenshots of what you're proposing (UI changes). Could you include these before I ask for reviewers?

I've added a screenshot. The labels etc are not "final"

[cassiezamparini]

@xitij2000 Thank you! As some of the reviewers might be unfamiliar with the progress page components can you also show a side by side screenshot of a one component turned on and off. It's useful for everyone to have better context within these reviews.

[xitij2000]

@cassiezamparini I've added a screenshot with all the new togglable components labelled.

[cassiezamparini]

@xitij2000 Thanks for the screenshots 😄 I like the idea of making this page more "configurable!"

I’m looking for reviewers, but I think these questions might help clarify things even more for everyone:

• What specific user goals are behind hiding each component? Understanding why users want to hide each of these elements could help determine if these extra customization options are needed for the broader community. For example, are there particular user groups or course types where these customizations are especially relevant?
• How often do course authors ask for this type of control? If there’s a strong demand across multiple clients, upstreaming the feature is more attractive.
• It might be worth exploring the UX, UI, and language options in the design to make things more intuitive. I found myself needing to switch between the configuration modal and the progress page to get a clearer sense of what each item referred to. Will this go through a design phase?
• How might these customizations affect learner experience? For example, hiding grades could be confusing for learners accustomed to seeing them, so an alternative explanation might be helpful.
• Should there be any guidance for course authors on the potential impact of hiding certain sections? This could prevent authors from unintentionally creating a disjointed experience for learners by hiding too many components.

[marcotuts]

This looks great!

I can't speak to how often people will change these settings, but the fact that we've cleaned up settings to better group things into specific areas (for example in Pages & Resources cards instead of Advanced Settings) makes me feel better abotu enabling 'more' settings here.

I will leave it to others whether all or just some of these should merge in as default settings and which should be a plugin only, but the idea of making this pluggable is great too. :D

[xitij2000]

I will leave it to others whether all or just some of these should merge in as default settings and which should be a plugin only, but the idea of making this pluggable is great too. :D

@marcotuts
I didn't see this as an either-or. Our particular client requires the ability to toggle them on or off, and so we've done that via slots because that can work even if this feature is not upstream. However, if the ability to toggle these has broader use, then we can add support for toggling them on or off in addition to making them slots.

@cassiezamparini
I will have to consult the client to get some of these answers, but I'll try to answer the ones I can.

It might be worth exploring the UX, UI, and language options in the design to make things more intuitive. I found myself needing to switch between the configuration modal and the progress page to get a clearer sense of what each item referred to. Will this go through a design phase?

The language can definitely do with refinement, currently it's named more around the names of the components in the code rather than the purpose they serve. Additionally, I can see some inconsistency around Enable vs Show and the casing. The design in itself is meant to fit in with the existing progress config page which currently only has two options, one for the page and the other for the progress graph. So there aren't too many ways to fit in. If this page is designed differently, it will not fit in with the other pages in this UI.

How might these customizations affect learner experience? For example, hiding grades could be confusing for learners accustomed to seeing them, so an alternative explanation might be helpful.
Should there be any guidance for course authors on the potential impact of hiding certain sections? This could prevent authors from unintentionally creating a disjointed experience for learners by hiding too many components.

I believe the client's use case might be when these components are not used, in which case showing them is likely to cause confusion as well.

The help text here can definitely be improved to guide along those lines. We can iterate on the best subset of options that represents the most common use-cases. For instance, bundling all grading related options into a single toggle or a single toggle with sub-toggles.

[marcotuts]

Our of curiosity is there any other detail or context on the client's use case that could help clarify when / why they might decide per-course to make different combinations visible on the progress page? (This only matters in the context of helping to assess how frequently this would be used by others if upstreamed.)

I'm trying to imagine a course level reason why someone would want some courses to reflect some combination of these progress page widgets and other courses to show a different set of them. These controls are easier to rationalize at the site level where you'd want to turn off a number of tools perhaps that aren't relevant to you, but it is a bit harder to see how frequently anyone would need this at the course level.

(As I look once again at the per-course level granularity provided by this, I'm reminded that the mobile application (currently designing the mobile app version of the progress page) would then need to respect these settings as well in the future if they were all default / included as options upstream.)

The controls remind me / echo the level of customization that some dashboard / page building tools would grant a user, so the pattern is one that does exist in some LMS options for sure per-course.

I could imagine an instance having 2-3 types of courses: standard, certification, and capstone. This example course 'type' isn't reflected by an existing setting but in this hypothetical you might have a single project submission in the capstone, and a practice test or two plus a final exam in the certification course type. Across these course 'types' you could imagine wanting to hide different areas of the progress page that feel less relevant, or (as I saw in another pull request - hide the dates tab?).

In other words perhaps there are mixes of courses where you'd like to hide larger areas of the course but keep them enabled elsewhere, but it still doesn't strike me as common a need to justify upstreaming the more I consider this and how this pattern would be echoed into other parts of the course tools / mobile apps / course-level apps.

[xitij2000]

@marcotuts I've asked the client for their input but haven't heard back from them yet.

I completely understand that perhaps the mapping should not be to elements on the progress page, but be higher level toggles that change the student and perhaps the authoring experience based on course-level toggles.

I will post an update here based on what I hear from the client.

[trabby]

@cassiezamparini We reviewed and compared our clients' requirements, and this issue was neither previously addressed nor customized. On the contrary, the new MFE progress features look promising, offering a granular view that could be further enhanced with gamification elements, such as an overall course status or anonymous statistics showing the number of other users enrolled, completion rates, and similar data to motivate learners to stay engaged.

Given the ongoing discussions around the review process and the need for data related to software changes, I believe that a single client request may not be sufficient to proceed with development. I’d be interested to hear from other providers and see if other clients would also find value in this feature.

[cassiezamparini]

@xitij2000 See above ^^

[yearimoh]

Hi @marcotuts and @cassiezamparini, I'm not sure how helpful this input would be given @trabby's comment above, but I will answer some of your questions for future reference:

What specific user goals are behind hiding each component? Understanding why users want to hide each of these elements could help determine if these extra customization options are needed for the broader community. For example, are there particular user groups or course types where these customizations are especially relevant?

• The main driving force behind this work is our completion-based course type. In this course type, the only requirement for certification is completion of course materials; assessment questions are present but they are ungraded. Since course grade does not matter, our instructional designers and course builders requested a way to hide the grade-related sections, especially the weighted grade summary section, as they found them to be unnecessary and even confusing in some cases for this course type.
• Re: Related links section, some of our courses have a single due date for all assignments (e.g. course end date). In this case, the Dates page becomes unhelpful. As for the course outline link, we thought this was redundant given that the Course tab is present/visible on the page; we also slightly concerned that its name deviation could introduce unnecessary confusion.

It might be worth exploring the UX, UI, and language options in the design to make things more intuitive. I found myself needing to switch between the configuration modal and the progress page to get a clearer sense of what each item referred to. Will this go through a design phase?

• I'm happy to improve them if this will be upstreamed.

How might these customizations affect learner experience? For example, hiding grades could be confusing for learners accustomed to seeing them, so an alternative explanation might be helpful.

• As mentioned above, our internal assessment was that seeing grades in completion-based courses was even more confusing than not seeing them.

Based on the comments above, I'm gathering that this course type might not be mainstream, at least in the B2C world. But we're seeing an increase in demand for this course type in the B2B market. Please let me know if you have any other questions!

[cassiezamparini]

Thanks for answering these questions @yearimoh. It's cool to understand the use cases in more detail.

@trabby I agree, I'd be curious if any other institutions have similar needs... let me ping a few people below...

• @marcotuts after reading YeaRim's explanation have you come across any requests like this from a previous client?
• @felipemontoya, @asma-ahmedd and @openedx/ccp-committer-jswope00 I'd also be interested to hear if any of your clients would benefit from this feature?