POAS Assignment development

Moodle 2.0

This is a proposition of Assignment module development from Volgograd State Technical University. I see no reason in keeping it as a separate module thanks to the trouble of backporting any fixes/improvments done in assignment. There is no reason to make it an assignment plugin too, as it will need a separate copy of each of the current plugins (online, offline etc).

Refactoring

Some areas of assignment_base class can be reworked for greater flexibility and reducing code duplication.

New Features

Workgroups

One main assumption in the assignment module is need to be eliminated is "one user=one submission=one grade". The quite common practice is grouped assignments, where students can work in small groups on a task. So we need a workgroup support there. (Well, quite big work as many functions use this assumption).

Workgroup is a group of students whose work will results in one submission. Workgroups features:

• teacher can define a minimum and maximum number of students in the group
• self-organisation (with possibility of confirmation by teacher) or forced by teacher groups
• maximum date of groups membership editing
• individual grading or per-group grading - there is one submission for the workgroup, but teacher may (or may not) want to give individual grades for the memebers
• teacher can add themselve to group as a mentor, then he only will be notified of events in this group
• 'roles' (or workroles to avoid confusion with Moodle Roles) of people in group (either teacher or student defined) this is a way to explain who in group will do what
  • teacher-defined roles is a list, from which one or several roles can be selected for students
  • if teacher doesn't want do define specific roles, students can enter text, explaining their role in the group

Individual tasks

Individual tasks is another quite common situation in the educational process. The module can handle tasks selection and completion.

Individual tasks features:

• adding/editing/deleting of tasks by the teacher
• standart fields: name, description, grade factor (1 by default), min/max workgroup number (if workgroups activated)
• custom fields, which can be added in any given assignment, of several types: string, text, number, date, menu
• student's selection (with optional teacher approval), teacher-forced selection or random selection based on a student's selection of subset of tasks fields (number or menu mainly, i.e. some sort of 'complexity' field for example)
• maximum dates of selection (and approval if necessary)
• column with task name (link to the task) when grading
• random filling of some task fields (number or menu mainly) on selection or approval
  • there is some problem of misuse of random generator; they are mainly dealed with fact that student's can change task and select new without teacher

User interface - tabs

Currently assignment have only two main pages: intro/submit (view.php) and grading (submission.php), so it can go away with the link in upper right corner.

New features will require more pages, so it's better to use tabs for them. Tabs visibility will be based on user's capabilities.

Plugins capabilities enhancement

• plugins can define their own tabs
  1. tabs can be implemented as classes
  2. tabs can be implemented as functions
• maybe plugins can add a columns to the grading table

maybe One user can get several tasks

That needs further discussion. It's something not very uncommon in real word teaching, but somewhat difficult to cope with "one course module=one grade" thing.

Tasks workflow

Let's see a task workflow in most complicated case (maximum features will be used). States names are somewhat awkward and is subject to change (can anyone propose better names?)

• initially task is free (1)
• (1) student or teacher can create a workgroup -> creating workgroup (2)
• (2) student(s) can add themselves to group, teacher can add students to group (in last case student notified that he/she was added)
• (2) students can refuse (if allowed) teacher assignment, teacher can disapprove (if allowed) members or task (students is notified if they are disapproved)
• (2) after the group will have at least minumum number of participants -> have enought people (3)
• (3) all (2) operatoins still available
• (3) students can confirm his will to work with group (now that he knows all it's memebers), teacher can approve a group - approvment automatically cleared if group membership changes (people that have approves is notified)
• (3) after the date of last approval, no more changes in groups available for students, (for teachers it's depends on capabilities), if there is an unapproved group the teacher will be shown (and sent) urgent reminder
• (3) after the students (if allowed) approved a group and task -> ready for work (4) (if teacher approvment needed) or working (5) (students and teacher notified)
• (4) after teacher approval -> working (5) (students notified)
• (4) in case of teacher disapproval -> have enought people (3) (students notified)
• (5) any student in workgroup can submit work with flag 'please check our progress' (if allowed), then teacher is notified and able to give comment but not grade (teacher notified, student's notified of comment)
• (5) any student in workgroup can make a normal submit, but it (optionally) may need an approval from other memebers for grading -> await grading (6) (teacher notified)
• (6) the teacher can only grade a workgroup in await grading status
• (6) teacher grades, but grade isn't final -> reworking (5) (students notified)
• (6) teacher gives final grade -> graded (7) (students notified)
• (7) person of higher authority will be able to override grade and add something to comment (but not freely edit it, the name of the first grader and regrader will be saved in comment). (students and teacher notified)

Well it's probably looked worse than is. The actual user will see only part of options, and all forms of approval can be disabled.

Implementation

New options

Let's see an assignment creation/editing screen. Assigment module will keep all existing options.

New options that will be added:

• use individual tasks
• use workgroups
• last date of approval - active if tasks or workgroups used, time to which all considerations about group memebrship and tasks selections must be done
• workgroup options (active only if workgroup selected)
  • min and max count of members of workgroup
  • the grade will be individual or one per group
  • if students must confirm it will to work with group (first student, who create a workgroup, may not be happy with someone who add youself to it later)
  • if teacher must confirm workgroup membership
  • if all workgroup memebers must confirm a submission before grading
• individual task options (active only if tasks is selected)
  • allow using same tasks - can several students do one task or all tasks must be different?
  • allow using same tasks in one group
  • individual date - allow individual due dates to the task
  • individual workgroup memebers count - if workgroups used, can particular task override min/max number of students in workgroup
  • teacher must confirm task selection

 Dmitry, can you please place appropriate screenshot there --Oleg Sychev 08:53, 3 December 2008 (CST)

DB structure

The new db structure have such tables:

• assignment - main table which have new options:
  1. maxmembersontask - maximum count of members which must to do the task
  2. minmembersontask - minimum count of members which must to do the task
  3. mintaskonmember - minimum count of tasks for one member(needs discussion)
  4. maxtaskonmember - maximum count of tasks for one member(needs discussion)
  5. timedistrib - initial time for task distribution
  6. timeconfirmation - the date after that a student not may create/come into new working group
  7. timereception - start time for tasks reception
  8. flags - all binary options
• assignment_tasks - table for task list of instance of activity:
  1. name - the name of task
  2. descripiton - task "body"
  3. deadline - individual date for task reception
  4. factor - factor for grade
  5. maxmembers - maximum workgroup members on task
  6. minmembers - minimum workgroup members on task
• assignment_fields - define list of custom fields:
  1. ftype - type of the field
  2. name - name of the field
  3. showintable - additional column in table of tasks
  4. maxvalue - maximum value for the field(only numbers)
  5. minvalue - minimum value for the field(only numbers)
  6. optional - optional field?
  7. rndparam - if this field used to define filter for random selection of task
  8. rndshow - if this field will get random value on task selection (number or menu fields only)
• assignment_field_consts - define consts for the fields type of list
• assignment_values - values for particular task/workgroup
• assignment_workgroups - table for working groups, also submissions stuff go there
• assignment_workgroup_members - members of working group, grade stuff go there:
  1. userid -
  2. grade - this is the grade for submission
  3. submissioncomment -
  4. format,teacher,timemarked,mailed - old fields of assignment_submissions
  5. ownrole - role which student want implement during task execution
  6. finalgrade - final grade(yes/no)?
  7. deletefrom - please kick me from this working group (or task)
  8. deletecomment - explanation why student needs to delete from this working group
• assignment_role - roles for the task:
  1. one task have many roles
  2. one student perform many roles

Tabs

Info/submit

This is an initial tab, that will work basically the same as before.

New abilities:

• show additional dates (i.e. dates of last approval and so on)
• student: show individual task (?tasks?) when the individual tasks is selected
• student: show task status (i.e. selected, approved, submitted, graded (but reopened), closed
• student: show workgroup members (when workgroups used)
• student: can approve group and submission, select or type his roles
• teacher: the number of submissions will be shown JFI as there is a tab for grading now (maybe as a link, just as in quiz now - maybe it must be moved to down center area)
• teacher: the number of submissions will be showed as <actual submissions>/<maximum submission>
• there will be an additional information - number of submissions that needs grading

Custom tasks fields

This tab is for managing custom fields for the tasks. The author can add/edit/delete fields there.

Tasks

New tab, accessible when individual task feature activated.

Abilities:

• teacher: adding, editing, deleting a task (editing and deleting assigned tasks may be prohibited)
• student: browsing task list, viewing task details
• student (without workgroups): selecting a task
• student (in workgroups mode): see current workgroups (at least uncomplete), create workgroup for a task, apply for workgroup membership (approved by teacher and/or workgroup creator), set workgroup in ready for work status

Grading

This is an evolved grading page (submission.php), for teachers use.

New abilities:

• the table will reflect a status of task (maybe with icons)
• individual tasks: the table will additionally reflect task name (as a link to popup with it's description) and a grade factor
• worgroups: the table (and popup for grading too) will have two modes:
• workgroups and/or individual tasks: in case any form of teacher approvment is needed, columns for approvment will be showed
• grade columns/popus will be showed only when grading is allowed (or if person has mod/form:gradeanything capability)
  1. groups grades - each string represent a workgroup
  2. individual grades - each string repesent a student, but they are sorted by workgroup and workgroups is spaced somehow
• make an option for the teachers to make any grade final, forbidding further re-submissions and/or regrading (maybe a person with hign priviledges can still regrade); in workgroups with individual grading mode re-submission will be forbidden only when all workgroup members receive final grade
• dropdown to choose whom to display in the table (and in the popup): all, with submissions only, needs grading only

 Dmitry, please add a screenshots there as soon as you will have them --Oleg Sychev 15:17, 1 December 2008 (CST)

Capabilities

Current capabilities

• mod/assignment:view - actually quite strange capability that can completely block you from assignment
• mod/assignment:submit - ability to submit a work
• mod/assignment:grade - ability to grade submissions

New capabilities

• mod/assignment:viewownsubmission (can be backported to 1.9) - sometimes we need to not allowing the student to see own submission (exams cases mostly)
• mod/assignment:manageanything - person with high authority, for whom don't apply usual restrictions: he can edit/delete tasks on which people worked right now, manage group membership and their tasks after an approval, override final grades and so on
• mod/assignment:managetasks - ability to create, edit and delete tasks
• mod/assignment:managefields - ability to manage custom fields of tasks
• mod/assignment:finalgrades - can make grades final
• mod/assignment:manageworkgroups - ability to create, force students to workgroup/task, approve students and tasks selection (teacher's ability)
• mod/assignment:managetaskselection - ability to manage tasks selection for any student (teacher's ability)
• mod/assignment:manageowngroup - ability to create new workgroup, apply to existing one, confirm memebership of the others in this workgroup (student's ability, setting it to Deny will create an assignment where only teachers can manage workgroups membership)
• mod/assignment:selectowntask - student's ability to select task (setting to Deny allows for teachers-only tasks selection)

Assignment base class reworking

Issues

1. there are number of functions closely related to one user=one assignment=one grade issue
   • submissions
   • update_main_listing
   • display_submission
   • display_submissions
   • process_feedback as it's assume userid in feedback, maybe process_outcomes too
   • get_submission, prepare_new_submission
   • print_user_files - troublesome function, it will still work with call in user_complete, but probably not work with display_submission (this call is quite strange, as it probably must be handled by plugin on the same basis as print_student_answer
   • reset_user_data
   • any grading-related functions
2. we must use new tabs system instead of submitted_link function
3. email_teachers function need reworking to get more options available, as there will be more events that need to be emailed to teachers
   • maybe we will need email_students function too?
4. all plugins override view function now, instead of one of it's subfunctions; this is quite strange and can be removed

New functions

1. Ability to add new tabs for plugins
2. Ability to add student's/teacher's notification events for plugins
3. Ability to override some parts of grading table for plugin (change the meaning of the rows and columns)