Enable finer-grained control over progress page components

xitij2000 commented 2 weeks ago

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[bot] commented 2 weeks ago

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

cassiezamparini commented 4 days ago

@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 commented 3 days ago

@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 commented 3 days ago

@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 commented 3 days ago

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

cassiezamparini commented 3 days ago

@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 commented 3 days ago

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 commented 2 days ago

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.

openedx / platform-roadmap