You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have reports of instructors setting highly restrictive availability dates on quizzes that end up causing issues with extensions.
For example, if an instructor sets a 60-minute quiz to be available from 8am to 9am, the quiz will end at 9am regardless of when the student begins the quiz. This also applies to students who receive time extensions, meaning a student who is supposed to receive double time would be recorded as having 120 minutes, but still be shut down at 9am, only 60 minutes after starting their exam. Part of the issue is that the instructor isn't necessarily aware that giving an extension doesn't override the available until time.
While the simplest solution is obviously to make the length of availability longer, not all instructors are amenable to this idea. The other option is to provide an overall time extension to just the affected students via differential dating.
Differential dating is outside the scope of the Quiz Extensions tool (not to mention I've had difficulty implementing it in Due Date Changer ucfopen/due-date-changer#11), but we can still do something to inform the instructor that they are making a mistake.
Proposed Solution
Add functionality to the extensions process to check for quizzes with availability dates and warn if the extension would exceed the due/lock date:
Determine the length of time the quiz is available for (subtract lock_at and/or due_at from unlock_at)
Compare that available length against the new extended length (time_limit * extension factor)
If the extended length is greater than the available length, flag that quiz
After all quizzes have been updated, display a warning message with a list of all the flagged quizzes stating that the instructor will need to add time for those students. Probably include a link on how to edit availability dates for individual students. (Maybe this one?)
At the very least, this will inform the instructor that action is still required of them.
The text was updated successfully, but these errors were encountered:
Expanding on this, the Quiz Extensions API endpoint has a parameter called extend_from_end_at that we might be able to leverage to automatically extend the quiz time for students who receive an accommodation. This will require some further testing.
There's also manually_unlocked which might be an even simpler path.
Problem
We have reports of instructors setting highly restrictive availability dates on quizzes that end up causing issues with extensions.
For example, if an instructor sets a 60-minute quiz to be available from 8am to 9am, the quiz will end at 9am regardless of when the student begins the quiz. This also applies to students who receive time extensions, meaning a student who is supposed to receive double time would be recorded as having 120 minutes, but still be shut down at 9am, only 60 minutes after starting their exam. Part of the issue is that the instructor isn't necessarily aware that giving an extension doesn't override the available until time.
While the simplest solution is obviously to make the length of availability longer, not all instructors are amenable to this idea. The other option is to provide an overall time extension to just the affected students via differential dating.
Differential dating is outside the scope of the Quiz Extensions tool (not to mention I've had difficulty implementing it in Due Date Changer ucfopen/due-date-changer#11), but we can still do something to inform the instructor that they are making a mistake.
Proposed Solution
Add functionality to the extensions process to check for quizzes with availability dates and warn if the extension would exceed the due/lock date:
lock_at
and/ordue_at
fromunlock_at
)time_limit
* extension factor)At the very least, this will inform the instructor that action is still required of them.
The text was updated successfully, but these errors were encountered: