I am starting this issue to continue the discussion started by raystuart in the drupal in education group at http://groups.drupal.org/node/6447#comment-68000. The intent of the submodule is to
Allow a teacher to release assignments on a per-student basis once some trigger condition has been met.

Examples:
Assignment #2 would not be available to Student A until the student has submitted Assignment 1.
Assignment #2 would not be available to Student A until the student receives a threshold grade on assignment 1.

The sub-module should:

  • Filter the list of assignments displayed in the gradebook on a per-student basis according to the criteria defined by the teacher
  • Allow the teacher to grade each attempt on an assignment, and track the student's progress

I think this can all be handled with the existing gradebookapi, though a couple of new submodule hooks might be needed.

Please let me know your thoughts.

  • What should this look like from the student perspective, teacher perspective, administrator perspective?
  • Assuming new forms are required, what should they look like?
  • Any other use cases to consider?

Comments

AntiNSA’s picture

There should be 2 perspectives on this
a) Targeting student redo for whatever the reason
b) ease of distribution for multiple classes/use (assisgn a lesson now and use the same one in the future with a different class or ability to assign multiple classes the same lesson)

I think that the ability to redo or revise a lesson should be carryied out in the way of listing the lessons in a master teacher layout, like the way you do now, and have a check box that allows the lesson to be redone/revised underneath the lesson name that can be checked anytime after the lesson is issued. The only problem is that would mean everyone has the permission to redo a lesson. You would also need a way to allow individuals make up oppourtunities without allowing the whole class a make up opportunity./

AntiNSA’s picture

I thinkt this issue follows 2 paths. One for perspective A ans listed in # 1 and one for Perspective B.

I think this thread should follow perspective A, and for perspective B the issue should be developed in this thread:

http://drupal.org/node/794460