For those joining us late, Moodle gradebook currently polls each activity module at display time and PULLS all the grades that a teacher or student may want to see.
Although this works OK now, the performance isn't good, and bogs down on larger classes. In future, since we want to have conditional activities (shown and hidden) based on grades we really need to improve the performance and allow things like grades caching etc.
So the new approach is to move to a PUSH model where the gradebook API allows modules to push data into a central table whenever things change. Obviously this is a major change that requires changes to all modules, but it needs to be done.
What I'd like to do is develop a spec for this first so we can have some general agreement on the direction. So as a first step, can we gather thoughts/code from anyone who's already done some thinking about this?
Here is what I have, some of these are intended to promote discussion and haven't been thought about in depth;
Hopefully this will promote some discussion.
- retain existing functionality; weighting, categories (allow nesting), curving/scaling, extra credit, drop the 'x' lowest, etc.
- statistics on a per grade item basis
- grade calculations only based on what has been completed in addition to total course points.
- allow gradebook only grades... avoids need to create an assignment/etc. for things that don't need the extra overhead
- allow spreadsheet-like editing, this can be sped up from gradebook plus with a centralized model as each entry can have a unique identifier that is a primary key in the db.
- allow locking from the module or from the gradebook. For instance quiz grades should not be editable from the gradebook while the quiz is still open. Alternatively an instructor may want to ensure that lesson or some other module grades are final after a certain date and lock them from being changed from outside the gradebook.
- conditional activities; not just singular activity requirements, option to require multiple activities
- export to other systems (XML, excel, etc.)
- import from other systems
- allow sensible implementation of scales (I think this may require work to the scales)
- maybe extend/implement user permissions to include gradebook grader; so an individual can add/edit grades in the gradebook but nothing else. Additionally they only see a single grade item (or a set of grade items) and not the combined grade data. Makes sense for homework graders or lab assistants.
- have a transcripting system that takes a 'snapshot' at a given date, this may overlap/integrate with some of the portfolio stuff others have been working on as well as "my moodle"
- allow cross course gradebook overview that shows individual grades across courses
- way to identify where the grade came from; will it be just modules that have grades? Or will it be possible for blocks as well as other things?
Hopefully this will promote some discussion.
Dear Martin,
On the CD-rom I gave to you last year in Portugal (during your World tour) You can see:
- the wish to have a marking mechanism for each activity (and resource: reading is also an activity) to declare it as a core activity
- then we need a table that gets information from each of the previous one:
- did the student visit this resource/activity page
- did the student start with the activity
- did the student finish the activity
- was the activity graded (what was the grade/set of grades)
- did the activity have the status of core activity
- It would be best when this table was filled by the modul (push) instead of filled any time when the table was needed.
- (put a flag in an extra "was changed field after previous look up")
- based on the content of this table it is possible to:
- paste a footprint in student view after the hypertext-link on the homepage of every visited page in studentview
- paste a "student did start icon" after that hyperlink in student view
- change that icon in "finished" when finished and "graded" when graded if that must me done by hand (of the teacher)
- paste an icon in front of the hyperlink in student/teacherview to mark the core activities as essential, must do..
- combine 2.3 and 2.5 and 2.7 to build the code for the graphics view I gave to you on the CD-rom
By all the changes, I have to rebuild all this for 1.6 and feel a little depressed
This was all to be implemented in the gradebook? It sounds like the ideas for a Transcript/Student Information System/Student Portal component, which probably should be external to the gradebook anyway?
No it is external of the gradebook, but it needs this central grades table where activities PUSH their results...
A rough time estimate for building the centralised tables might be helpful.
For a suggested development model (assuming no one comes up with the resources to do the whole thing the right way in one shot):
Start with the graded item in the gradebook, develop a table structure for the first grade table internal to the gradebook. This also solves the problem our faculty have with adding items in the course when they only want them in the gradebook.
This would provide an integral (to the gradebook) table structure which then can be modeled for other modules. We could also use it to model the functions to return and calculate grades from the central tables.
For a suggested development model (assuming no one comes up with the resources to do the whole thing the right way in one shot):
Start with the graded item in the gradebook, develop a table structure for the first grade table internal to the gradebook. This also solves the problem our faculty have with adding items in the course when they only want them in the gradebook.
This would provide an integral (to the gradebook) table structure which then can be modeled for other modules. We could also use it to model the functions to return and calculate grades from the central tables.
The ability to translate percentages to custom scales 90% becomes a "good" ( I know, what a pain)
The ability to script a final grade calculation (if mark_mode>mark_percentage then....)
Not related to the push model....
more than one mark generated for an assignment
rubric marking ( check the appropriat level in the rubric, rather than a dropdown)
The ability to script a final grade calculation (if mark_mode>mark_percentage then....)
Not related to the push model....
more than one mark generated for an assignment
rubric marking ( check the appropriat level in the rubric, rather than a dropdown)
The PUSH model is probably the best approach, since it standardizes the way in which grades are accessed. I think once that change is done, performance should be less of a concern. Right now the solution implemented is perhaps too modular.
There are a couple of things I would like to see in the centralized gradebook. The suggestions below contain a few mockup interfaces mostly for visualization purposes. Two major problems I see with the gradebook now for use on a secondary level is that grades can't be segmented into terms, and grades cannot be designated as historical.
Terms could be as simple as allowing the instructor to segment their gradebook into terms such as 1st quarter (Q1), 2nd quarter (Q2), 3rd quarter(Q3) and 4th quarter(Q4). If it was a university, the term could just be a semester code for semester 1 (S1) or semester 2 (S2). But with each term would be an associated final grade. The setting up of terms should probably done on an institution wide level and just associated with courses, since many teachers would have the same exact term setup it would be silly to have them have to set up each term on their own. Right now the gradebook isn't useful for secondary schools in the U.S. mostly because we go by a terms based setup, so as grades accumulate the only thing that matters to us is the grades in the quarter we're in now. However, a final course grade should be able to be calculated as well as some composite of term grades and regular course grades.
Second, each instructor should have their own set of grades that they control within the centralized table just like in real life an instructor has their own gradebook. However, it should be possible at the end of a given term to make a copy of those grades and designate them as historical. Historical grades are things that would appear on grade reports, transcripts, used to calculate credits earned, etc. This functionality should be done at the institution level, where some administrator presses a button and all instructor grades are copied into a table that is permanent. A basic grade change interface should be available in the event of a serious problem.
Everything beyond this are some ideas for the term setups for grading. Mostly in terms of data structures / UI representation.
---
Michael Tanczos
Term Setup Each course should be associated with a given year, making it possible to retain historical courses in the database. A term code with id of 1 will be used by default to designate a class that is ongoing. Terms are represented as a hierarchy. The minimum term that must be set up for courses to be set up is the full school year term.
Key Fields:
- id
- Term Name
- Term code (e.g. Q1 for quarter 1, S1 for semester 1, etc)
- Start Date
- End Date
- Term Portion (int) Portion of the year this term represents. 1 (school year), ½, 1/3, ¼, 1/5, 1/6, 1/7, 1/8, 1/9, 1/10, 1/11, 1/12
- timemodified
Date format listed as MM/DD/YYYY
S A M P L E Y E A R S & T E R M S D I S P L A Y I N T E R F A C E
------------------------------------------------------------------------------------------------------------
[ Add New ]
Year | Code | First Day | Last Day | Edit Terms |
[2002 2003 School Year] | 02-03 | 8/28/2002 | 6/4/2003 | [Edit Terms] |
[2004 2005 School Year] | 04-05 | 8/28/2003 | 6/4/2004 | [Edit Terms] |
[2006 2007 School Year] | 05-06 | 8/28/2004 | 6/4/2005 | [Edit Terms] |
------------------------------------------------------------------------------------------------------------
S A M P L E Y E A R S A D D / M O D I F Y I N T E R F A C E
------------------------------------------------------------------------------------------------------------
Add New School Year
Option / Value
Name of Term: [ ]
Code: [ ] e.g. 06-07
First Day of Term: [ ] (MM/DD/YYYY)
Last Day of Term: [ ] (MM/DD/YYYY)
------------------------------------------------------------------------------------------------------------
Special Notes: The above functions identically to the term add/modify interface. Its sole purpose is to create/edit school year terms. All term divisions must be based off a given school year. A university school year might be split into several semesters that span the entire year, with particular courses being set up for different semesters. The term portion will always be set to 1, representing a full year.
S A M P L E T E R M D I S P L A Y I N T E R F A C E
------------------------------------------------------------------------------------------------------------
[ Add New Term ]
2005-2006 School Year Y1 8/28/2006 6/4/2007 | |||||||
Semester 1 S1 8/28/2006 1/17/2007 | Semester 2 S2 1/18/2007 6/4/2007 | ||||||
Quarter 1 Q1 8/28/2006 11/1/2006 | Quarter 2 Q2 11/2/2006 1/17/2007 | Quarter 3 Q3 1/18/2007 3/14/2007 | Quarter 4 Q4 3/15/2007 6/4/2007 | ||||
Rotation 1 R1 8/28/2006 10/20/2006 | Rotation 2 R2 10/21/2006 12/11/2006 | Rotation 3 R2 12/12/2006 2/9/2007 | Rotation 4 R2 2/12/2007 3/23/2007 | Rotation 3 R2 3/26/2007 6/4/2007 | |||
Or
No Terms Currently Exist
(each term listed links to the edit term page)
------------------------------------------------------------------------------------------------------------
S A M P L E T E R M A D D / M O D I F Y I N T E R F A C E
------------------------------------------------------------------------------------------------------------
Option / Value
Name of Term: [ ]
Code: [ ]
First Day of Term: [ ] (MM/DD/YYYY)
Last Day of Term: [ ] (MM/DD/YYYY)
What portion of the school year does this represent? (½, 1/3, ¼, , 1/12, etc dropdown list)
------------------------------------------------------------------------------------------------------------
Grade Scales The current implementation of scales on a module by module basis is okay, but is problematic when you wish to implement it into a gradebook because it becomes impractical to average text-based grade scales.
Key Fields:
- id
- Grade Scale Name
- Description
- Is Default Scale? (only one scale can be considered the default scale for an institution)
- timemodified
Scale Properties (an individual scale will consist of a series of records created from the following fields)
- scaleid
- Grade (e.g. A, B, C, )
- Description
- Grade Points, float (e.g. 3.0, up to 200)
- grade_low (low end of grade range)
- Gradebook Value What numeric value the gradebook will use when a teacher enters in the grade code into their gradebook. For example, if a teacher enters a B+, the value that B+ translates to could be an 88
- Counts in GPA? (checkbox) In the event that this scale is actually used in the gradebook, you may want to have the option of not counting this type of grade in the overall GPA.
- Receives Added Value (checkbox) Can the instructor add a point total beyond the defined Grade Points value?
- Available to Teachers (checkbox) Is this scale available for use by instructors?
Example Scales:
Scale Name: Default
Description: This is the default scale used by all courses if none is set.
Grade: A
Description: Excellent
Grade Points: 4.0
grade_low: 93
Gradebook Value: 95
etc etc.
Scale Name: Numeric Scale
Description: This scale would have 100 different records to define numeric grades
Grade: 100
Description: 100
Grade Points: 100
grade_low: 100
Gradebook Value: 100
etc etc
Grade: 99
Description: 99
Grade Points: 99
grade_low: 99
Gradebook Value: 99
etc etc
Additions to $PREFIX_course record:
term_list (most likely something like a Y1 for year, or an S1 if it is semester-based in fall, S2 for spring, S3/S4 for summer, etc. It depends on the term setup. The id would match up term codes to the terms records defined by the administrator)
gradescaleid Defaults to the default gradescale and will remain with that scale after course creation, even if the default scale is switched to some other scale.
Attached is a document containing some ideas I was fleshing out for improving the gradebook as well as adding in more SMS type features, but I think most of the focus should be on the gradebook related stuff near the end.
Just to give an overview of some of the suggestions I've made are intended to fix:
Some clarification on what is seen below. The chart below allows you to set up multiple final grades based on the terms that were defined. So you can see under the first row, "Y1" would represent a final grade to be calculated for the entire year. Q1 would represent a final grade for the first quarter in the third row, Q2 for the second quarter. The important thing to note is that each final grade would have to have a date range associated with it that takes place within the term it should be defined within. Then you can represent things like a midterm exam by setting aside a special day to designate it as a "midterm" day. Then any assignments added for that date would get calculated as a midterm.
You can see under Quarter 2 there is a [Q2] *and* a [E1] code. If the range for quarter 2 was from say.. November 15 to December 15. The Q2 final grade range might be set up for November 15 to December 14, and the E1 (midterm or final exam) final grade could be set up as December 15. Then all assignments within the Q2 final grade range count towards the Q2 final grade, and all assignments within the E1 (midterm exam) range of one day would count towards that students final exam. It would be important later on to give the instructor flexibility in determining each final grade as a composite of assignments within that range, or even extend it to be a composite of selected other final grades. So we might weight Y1 to be 20% of Q1, 20% of Q2, 10% of E1, 20% of Q3, 20% of Q4, and 10% of E2 (20+20+10+20+20+10=100%).
The rotations shown are just to show more possible divisions of time. Not all classes would be defined to utilize terms on that level.
Q1, Q2, E1, Q3, Q4, Y1
As they fill in assignments throughout the "year" each final term grade would be updated based on the assignments contained within that term. Again, the instructor should be able to configure how each term final grade is calculated however.
- Segmentation of grades into terms
- Storage of permanent "historical" grades for transcripts, gpa calculations, graduation credit calculations, grade reports** (probably most important)
- All existing weighting methods could be retained both for individual assignments and also for final grade calculations
- "graded items", as defined in the Moodle_Enhancements2.doc could be used to define separate assignments that don't come from a module
- easy access to export data from the centralized table
- cross course viewing of student grades from a dashboard display - as a course progresses they can see the instructors non-historical grades. They can also see the final grades they are assigned as the year progresses.
- a separate table may be created to assign comments to individual grades if desired
- the ability to create customized scales and also define codes that have a special meaning. Like if I put "T" into my gradebook, to me I could take that to mean that the student was absent and the corresponding grade is a zero until they make up the missed work.. but at least I can see why they don't have a grade there yet in the mean time. See the "grade scales" portion, where userid = teacher's user id.
- the ability to override module grades with a grade of the instructors choosing. This does not change how the module itself calculated the grade (so the original module grade gets retained), but would simply be a new value that would override the old module grade.
Some clarification on what is seen below. The chart below allows you to set up multiple final grades based on the terms that were defined. So you can see under the first row, "Y1" would represent a final grade to be calculated for the entire year. Q1 would represent a final grade for the first quarter in the third row, Q2 for the second quarter. The important thing to note is that each final grade would have to have a date range associated with it that takes place within the term it should be defined within. Then you can represent things like a midterm exam by setting aside a special day to designate it as a "midterm" day. Then any assignments added for that date would get calculated as a midterm.
You can see under Quarter 2 there is a [Q2] *and* a [E1] code. If the range for quarter 2 was from say.. November 15 to December 15. The Q2 final grade range might be set up for November 15 to December 14, and the E1 (midterm or final exam) final grade could be set up as December 15. Then all assignments within the Q2 final grade range count towards the Q2 final grade, and all assignments within the E1 (midterm exam) range of one day would count towards that students final exam. It would be important later on to give the instructor flexibility in determining each final grade as a composite of assignments within that range, or even extend it to be a composite of selected other final grades. So we might weight Y1 to be 20% of Q1, 20% of Q2, 10% of E1, 20% of Q3, 20% of Q4, and 10% of E2 (20+20+10+20+20+10=100%).
The rotations shown are just to show more possible divisions of time. Not all classes would be defined to utilize terms on that level.
F I N A L G R A D E S E T U P
This section provides an interface to set up final grades as
they appear in the gradebook. It starts by using the hierarchial term list established by creating the terms. Initially each column contains an [ Add Final Grade ] link, but as final grades are entered in they start to show up to the left of the [ Add Final Grade] link.
|
2005-2006 School Year Y1 [Y1] [ Add Final Grade ] |
|||||||
|
Semester 1 S1 [ Add Final Grade ] |
Semester 2 S2 [ Add Final Grade ] |
||||||
|
Quarter 1 Q1 [Q1] [ Add Final Grade] |
Quarter 2 Q2 [Q2] [E1] [ Add Final Grade] |
Quarter 3 Q3 [Q3] [ Add Final Grade] |
Quarter 4 Q4 [Q4] [E2] [ Add Final Grade] |
||||
|
Rotation 1 R1 [ Add Final Grade] |
Rotation 2 R2 [ Add Final Grade] |
Rotation 3 R2 [ Add Final Grade] |
Rotation 4 R2 [ Add Final Grade] |
Rotation 3 R2 [ Add Final Grade] |
|||
A grade storage code can be set up for any of the terms established in the term setup area. Each of these codes will appear in the gradebook for each course depending on the terms the course runs over.An instructors gradebook with the term setup above might look like this:
Q1, Q2, E1, Q3, Q4, Y1
As they fill in assignments throughout the "year" each final term grade would be updated based on the assignments contained within that term. Again, the instructor should be able to configure how each term final grade is calculated however.
---
Michael Tanczos