Gradebook

A simple example is the assignment module. The student's work gets a single grade. Should that be stored in the gradebook, or in the assignment module, or both?

Back before Moodle 1.9, it was stored in mod_assignment, and fetch by the gradebook every time the gradebook was displayed. This was a performance disaster.

In Moodle 1.9+, the grade was stored in both mod_assignment and in the gradebook. This was a mess.

In the new mod_assign (Moodle 2.3+) the grade is now only stored in the gradebook. Of course, it is still visible and editable in the assignment UI.

So, actually, this problem is solved in principle. The grade should be stored in one place (the gradebook), but the UI for seeing and editing that grade value can be shown wherever is appropriate.

In software terms this is an MVC approach. There should be a clear Model in the background to manage the data (and this is part of the gradebook code), and then as many Views and Controllers as necessary to display and edit the grade.

The good news is that in all the discussions that I have had with other developers about this, no-one disagrees with this principle.

The bad news is that this principle was not clearly established until after the current gradebook was created so lots of parts of Moodle do not follow this principle. (E.g. the quiz_grades table still exists.) Fixing that will not be easy.

If you look at the properties of grade_grades and grade_items (either the class definitions, or the database tables) then it is not clear that the data we have is quite right for what we really need.

Fortunately, it is not bad. As I said before, the gradebook works for most people most of the time. But still, solving some of the other problems will only be possible with a change to the model, and it is not clear how the model should be changed to solve all the problems. Working that out will require some serious, deep requirements analysis.

Some examples of some specific problems with the model:

1. Let's start with the good news, one that was solved in the past. It used to be impossible to have 'extra credit' activities, beloved of the Americans. Now you can.

2. However, I think it is still not possible to have grades above 100% or below 0%, and perhaps it should?

3. The thing we have been arguing about in the other thread: Should the visibility of the grade item be a separate concept from the visibility of the corresponding activity, or one and the same?

4. At the moment whether a grade item is visible can have three states: Hidden, Visible, or Hidden until a given date. It is not clear that third option should really be build into the data model. The alternative is to have grade items be either hidden or visible at any one time, and if you want that to change automatically at a set time, should have a separate plugin that makes that change at the right time.

5. I am about to explain another issue as Problem C.

Note that it is not just enough to have a model that is logically self-consistent and lets us write bug-free code. We also need to have a model that makes sense to teacher. Of course most teachers should not need to understand the full model. As I say, simple scenarios work for most people with the current faulty model. But there will always be power-users, and we should be able to explain the full model to them if they are interested.

This can best be described with a specific scenario.

1. Student attempts a quiz and scores 50%. This is reflected in the gradebook.
2. Teacher manually edits that grade to 60% in the gradebook.
3. Student makes a second attempt at the quiz, and now scores 70%.

What should the student's grade be now? (In the gradebook UI and the quiz UI, but hopefully the answer is the same in both places.)

You can vary that scenario by changing the grades. Is your answer the same in all cases? Also, this does not only apply to the quiz. It also applies to the Workshop, or a rated Forum, or even a calculated grade item in the gradebook, or the course total.

I have been asking this question, on and off, for years, but have never got an answer. In fact, I don't think there is one right answer to this, we will just have to pick one, and declare Moodle works that way, but we should try to pick one that works best for teachers more often than not, and I don't have an opinion about this.

Note that in terms of the current Moodle code, this is handled by things like locked grades, but that does not work very well, and often leads to confused people asking questions here, so that suggests other parts of the model to review.

OK, I am going to shut up now. I think those are the three most serious problems, but I could well be forgetting more. I hope that was helpful to someone. Please feel free to add to this list.

This one is very complicated, because much of the gradebook structure seems to be built on this assumption, but if we are going to think big here...

A design assumption in much of the gradebook is that all users will have the same number of possible points. This causes bad computations in categories with drop highest/lowest X settings, and group members only (different activities for different groupings). You can get around these by using certain aggregation modes and settings, but the result if far from clean - usually with the student seeing that they are getting a way lower score than expected.

Let me try to do this in a less fragmented manner instead of commenting everywhere.

1. No extra credit in weighted mean.
2. Letters grades are fundamentally broken.
   1. Letter grades are rounded to 2 decimal places regardless of teacher's preferences. So students may see a 90, which they know from their syllabus that that equals an A, but they receive a B, due to the 2 decimal rounding.
   2. Letter grade boundaries are integers.
   3. Letters are arbitrary. In schools with rigid grading scales and letters that their SIS will accept, this is a nightmare.
3. Sum of grades is fundamentally broken.
   1. SUM doesn't work when you ignore empty grades.
   2. SUM doesn't work when you exclude items.
   3. SUM doesn't work when you drop lowest or keep highest.
4. The grader report has "some" usability issues.
   1. The grader report needs a user adjustable repeat headers setting.
   2. There's no way to know what your weight is outside of the edit tree.
   3. There's no way to edit one grade item's grades or one student's grades without everything else cluttering the screen up.
   4. Category overrides are the BANE of millions of users existence.
   5. Overrides in general are FAR too easy too create and FAR too hard to undo and get teachers into lots of trouble.
   6. Overridden grades are not obvious.
   7. In large courses, there is no way to assign 99 1 point grades and five 0 point grades without entering them by hand when grading homework.
   8. Large grade books are very difficult to find a particular student in.
   9. Leaving the grader report without saving DOES NOT GENERATE A WARNING!
5. Drop lowest is fundamentally broken.
   1. When a student only has two items out of five and mid-term grades are due, if the teacher is dropping two grades, the student has a 0 for their mid-term grade even if they have to 100% scores.
6. Weighted extra credit only makes sense to aliens.
7. Manual grade book items have a grade: none option, which is evil and cruel. If you create a manual item and set it to grade type: none, you are screwed and can never see that item again to update it or delete it without DB exploration.
8. Manual grade entries behave differently than every other grade entry. They cannot be offset and they can not have a multiplicator because of this.
9. CSV importer is fundamentally flawed.
   1. CSV import dies whenever it encounters an issue and you're left to wonder when, where, and why it died.
   2. If a grade item is locked, CSV importer will happily overwrite said grade.
10. max_input_vars limitations throughout.

That's all I have off my head right now. 

Someone who wishes to remain anonymous sent me some things in an email. (What a pain.) I am just copying and pasting it here. (Really, these are good points. Not need to be ashamed about posting them yourself.)

1. We use the Moodle gradebook for all of our courses and have the integration with Banner – all final letter grades are sent from Moodle to Banner.
2. The most common mistake my faculty continue to make is adding only a Category to the gradebook and not adding a graded item to the category.  They then add the grades to the category and the aggregation does not work.  I would like to see a message or a block that would say in creating a category you must add a graded item to the gradebook.  Or block the teacher from adding grades directly into a category.  I realize that will not work since it would block the ability to edit the category – but I have done workshops, videos, announcements and as many ideas as I can manage – but it still an issue. 
3. We need rounding – it is required.  I am working with Pukunui and they will be contracted by us to allow editing pass the decimal point.  In writing to them they stated that once this is done and working properly it will be submitted to Moodle to become a part of the core.  I know many folks would like to see this.
4. We end up with all of the grades – especially the Course total being overridden.  It would be great if there was a way to restore the course total for each student and uncheck the overridden box – for all students at one time – instead for having to do each student one at a time.
5. My math faculty has also asked for more in-depth information about the Moodle calculation – can the teacher see the full formula being used to calculate the student’s grade – especially in seeing if only non-empty grades are being calculated and if the lowest graded item(s) are being dropped. 

Tim above and others do mention problems with the override of grades functionality, and the fact that grades are stored in more than one place, and I agree that this is a problem fundamentally.

Other usability issues that are critical for us (in v. 2.5):

1) There is no way to enter an arbitrary number into the "Grade" field when setting up an assignment.  A pulldown of 100 values is unweildy.  And worse, some of our faculty want to have assignments on larger grade scales.  A "max grade" should be able to be any number the instructor wants and not limited to a pulldown of range 100, with some other custom scales.

2) When overriding grades, in the gradebook the grade item becomes shaded, but the consequences of overriding grades in the gradebook are not clear to most instructors and the shading should have a footnote or key at the bottom of the report stating something akin to "Shaded grades are overridden."

3)  Un-overriding grades is cumbersome.  If a user manually selects an overridden grade in the gradebook and clears the entry, the grade still stays overridden (overridden to be empty).  Fields with no content in other places on the form have a different meaning.    If a professor overrides a number of grades accidentally (easy and quick to do) then the user must go to each individual grade setting to undo this action (very tedious and time consuming).  If entering a grade in a field overrides a grade, then clearing a grade to match the other fields should un-override the grade.

4) Grade items should have a short-name and a full name to make the full grader view easier to use.  The grade column headings are as wide as the assignment or item name - often 20 or more characters - with only 4 or 5 characters sometimes in the row data for each student.  This makes the whole grader view basically totally unwieldy.

5)  It should be possible to "turn editing on" in the grade User Report, so that those grades for an individual student can be edited or overridden if necessary.  The absence of this is somewhat inconsistent.

Thanks for all of your work to make Moodle great though, in spite of the gradebook's evolving weirdness.

Consider this an echo of many of the issues highlighted here already. I'll add my two (current) issues with grades; one is a basic design premise, the second is for those really wanting to leverage it but can't.

1) Populating a gradebook with items from scratch using real course activities is done outside of the grades module. On first glance, one might understandably start creating grade items manually from the categories and items tab with the intention to create activities that coincide with the gradebook structure. Little do they realize that now there are two grade items for each activity and a bunch of wasted time creating manual grade items initially.

2) Custom calculations do not support (as far as I can see) a way to aggregate using "=product" functionality of multiple graded items. Would be nice to define a grade calculated on the percentages of many items; for example

=product(assignment1,asignment2,assignment3)

This grading design provides incentive for students to maintain consistent quality work as future poor results negatively impacts scores from previous work. Would love to find a way to do this. Perhaps someone knows a way?