Set Due Date and Grading for the entire section (chapter)

[Agrendalath]

Abstract

We have a client who wants to be able to set the due date for an entire section rather than the tedious steps of setting the same due date for each subsection manually. Currently, the editor does not show the Grading or Due Date Editor for chapters; they are only shown for subsections or any Sequential block.

Context & Background

We proposed this in 2018, then created a Platform Development Proposal in 2019 and sent a few emails over the last few years, but the product review was never completed. Hopefully, with the new process of the platform roadmap, we will move this forward.

Scope & Approach

Two potential approaches

1. Allow for Inheritance from Sections
   One possible solution is allowing sections to have their own grading schemes and due dates. This could work similarly to the release date inheritance mechanisms. Some basic initial testing shows that this sort of inheritance nearly works in its current condition when the ReleaseDateEditor and GradingEditor are enabled for the chapters. Still, much manual testing might be needed to ensure nothing is broken by editing this, and automated tests should be added for the inheritance here.
   The benefits of this approach are that it works similarly to other inheritance mechanisms users are familiar with when setting release dates, for instance. Also, this wouldn’t require many changes to the UI, as the grading editor is fairly general-purpose and will likely work on sections in the same way it works on subsections.
   The downsides of this approach are that it may require changes to the grading architecture, and we would have to ensure there are no bugs related to double-grading, or issues arising from different grading types between sections and subsections. Much of this might be handled already by the InheritanceMixin, which already allows for grading and due date inheritance.

2. Add a UI to set the Grading Type and Due Date for each Subsection
   Another possible solution is to add a UI element or editor within the course editor, which will propagate the due date to subsections of the section. This method would require fewer alterations of the backend and grading code, as sections would still not be marked graded, but it would be easy enough to set the same date for all subsections within a section.
   The downsides of this approach are that if specific due dates are set for some subsections, they would be overwritten by a UI element that sets the same due date for all subsections of a section. This would also require far more UI changes, and there isn’t a clear place in the UI to add such an interface. It doesn’t readily fit in with the other current UI elements.

Value & Impact

Improving the quality of life in course authoring in Studio.

Milestones and/or Epics

Original document: https://docs.google.com/document/d/1WtsrMXAh5r4FyVho2urTlV7iCTx_vwXjOa6FFWR86Q8. It contains some helpful comments.

Named Release

Timeline

Soon, hopefully.

Proposed By

OpenCraft

Additional Info

No response

[github-actions]

Thanks for your submission, @openedx/open-edx-project-managers will review shortly.

[jmakowski1123]

Thanks @Agrendalath ! Could you either set public permissions on the google doc, or paste the content into this ticket?

[Agrendalath]

@jmakowski1123, sure thing, I made the doc public.

[jmakowski1123]

Thanks for this submission @Agrendalath .

First, how widespread of a request is this, from your perspective? Is it a single client request? Have you heard it many times since your first proposal in 2018?

Approach 1 feels like the riskier approach to me, given the required changes to the grading architecture. A future core product project will be to consider the grading schema platform-wide, and for now it's preferable to stay away from any singular changes that would get into that space.

I wonder if there is an MVP way to implement this within the subsection level, rather than at the section level (for now). For example, a toggle option to apply due dates in a subsection to all subsections in the section. So here:

And would require very clear messaging about overrides, limited to the subsections within Section X, etc.

However, this might be a hacky workaround and would require a lofi prototype and some usability testing. Is that something you'd be in a position to take on?

[Agrendalath]

@jmakowski1123,

First, how widespread of a request is this, from your perspective? Is it a single client request? Have you heard it many times since your first proposal in 2018?

Yes, this is a single client request. They have many subsections in each section of their courses, and the major pain point is updating each subsection individually for every course run. It's tedious and error-prone; there are two fields ("Due Date" and "Due Time in UTC"), and most users have only a single clipboard in their OS. Therefore, they cannot simply copy-paste everything in one go.

@Kelketek, could you let me know if you're aware of any client feedback about setting the due dates individually for each subsection instead of doing this on the section level? The client we are talking about here is from BB-124 (private link).

Approach 1 feels like the riskier approach to me, given the required changes to the grading architecture. A future core product project will be to consider the grading schema platform-wide, and for now it's preferable to stay away from any singular changes that would get into that space.

Thank you for the explanation. This was the preferred approach for our client, but I can re-discuss this.

I wonder if there is an MVP way to implement this within the subsection level, rather than at the section level (for now). For example, a toggle option to apply due dates in a subsection to all subsections in the section. So here:

This is an interesting option, but I feel it's too hacky from the user's perspective. As a user, I would not expect any button in the subsection settings to modify other subsections. Having this option in the section settings feels more intuitive because we would be propagating these changes to its children. Even if we made it temporary, wouldn't it confuse users if we moved the settings around?
From the developer's perspective, implementing this MVP would require an identical effort to Approach 2 (or maybe even higher since we would need to retrieve the children of a parent XBlock).

[jmakowski1123]

Got it, thanks for the context @Agrendalath .

Re: Approach 2, I guess I'm not as concerned about the fact that there's currently no place in the UI for this setting live at the section level. That could be explored in some lofi frames. And there could be a clear warning message about the override behavior.

Do you have space in your plan to create some lofi frames?

I'm also tagging @ormsbee for a quick review of the two proposed approaches, to see if he has any flags about approach #1.

[Kelketek]

@Kelketek, could you let me know if you're aware of any client feedback about setting the due dates individually for each subsection instead of doing this on the section level? The client we are talking about here is from BB-124 (private link).

I'm afraid I don't know much more about this than you, @Agrendalath , but @tecoholic might.

[ormsbee]

I think approach 1 is fine, so long as:

• It follows current inheritance conventions, where the subsection can override any start/due/assignment-type values that it inherits from the section.
• We clearly surface that behavior in the UI, and distinguish between "you have set this date for the subsection" and "this subsection is due on this date because it's inheriting it from section". We can have an explicit button that lets them reset all subsection grading information to match the section.

Some power users already use inheritance to specify start/due dates at the root CourseBlock level and let things inherit down, so we know that part of it works. I agree testing needs to be done about inheriting the assignment type, but that seems straightforward.

Minor caution note: If we decide to make a "force subsections to use section setting" button (e.g. if you have a bunch of subsections that already have specified values and you want to reset them to the section's values), we should make sure to do it in an explicit modulestore bulk operation in to avoid a bunch of publishes going in serial because sequential types auto-publish.

Most of the trickiness of this is probably going to be in the UX side of things.

Is this planned to go on top of the new Studio MFE? Or is the desire to make this available to older releases as well?

[Agrendalath]

@jmakowski1123,

Do you have space in your plan to create some lofi frames?

Of course. Once we agree on the approach, we can prepare the designs for approval.

@ormsbee,

Is this planned to go on top of the new Studio MFE? Or is the desire to make this available to older releases as well?

We will internally backport this to Palm (or maybe even Nutmeg), so we would like to make this compatible with both Studio frontends.

[Agrendalath]

@jmakowski1123, I'm just checking if we want to move forward with the first approach.

[Agrendalath]

@jmakowski1123, checking again if there are any blockers here.

[Agrendalath]

cc: @mphilbrick211

[jmakowski1123]

No blockers. Can you please share the frames as discussed?

[Agrendalath]

@jmakowski1123, got it - I wanted to confirm the approach before moving this forward. We will prepare the initial wireframes, then.

[Agrendalath]

@jmakowski1123, we need to postpone this until the second half of this year due to some reprioritizations.