Your screen shots do suggest a clear improvement, especially in terms of being able view and adjust the gradebook configuration on one page.

I am sure we can get some teachers to test it quickly for usability once that is ready and try to coordinate with others to provide some useful feedback of end users.

Since I teach with this and work with my faculty, I would anticipate some candidates for improvement just from looking at your screenshot:

• The weight of most interest is that of the categories. That does not appear to be shown. Perhaps it is when the parent category is Weighted mean of grades, but your sample does not show that.
• It is not evident to me what the symbols next to the category do. I assume that the first one is for empty = 0, but I am not sure which would be true or false. I don't know what the other two symbols do, and I am pretty familiar with the gradebook.
• Extra-credit is normally just true or false (and easily understood). Perhaps it is too late to change that, but I don't know how teachers are going to make sense of it being a number without careful training.
• You may just want to print text of any deviations from the defaults next to any item or category where that applies, and give an edit icon to change an item. That would keep the screen uncluttered in the standard case and give a quick visual indication of potential problems. The three icons would probably be better understood with text also (and only when different than the default).
• This is probably too big of a change of this iteration, but it would be nice to have the option to display a particular student's score next to each item and category so that one is not having to switch back and forth between pages to see the impact of a change.
• I still think that teachers are going to having difficulty finding this screen unless it is a tab or button labeled "Gradebook configuration".
• I would be very interested in seeing how this looks for my gradebook tutorial as I think that it would be more typical of gradebook setup than one with a complex set of rules and summary types. When it is stable enough to be tested, I will do that and can offer more detailed feedback.

Still, this is definitely a nice step forward and I look forward to seeing how it evolves.

--Gary

Thanks a lot for your feedback, you continue to be a great resource to Moodle

The screenshot was not in sync with the latest patch I posted, so I've updated it now. But now it's the patch that needs updating, since I've changed the extra credit to a checkbox. However, extra credits apply to 2 aggregation strategies: Sum of grades and Mean of grades with extra credits. I am not sure if the checkbox is used for both of these aggregation types.

We will most likely NOT show any grades on this page, however. It would become too crowded IMO and people will complain again that it's too complex and they prefer 1.6 blah blah blah.

As far as teachers finding it difficult to find the screen, it's not much of a learning curve in comparison with the other features. Personally I don't think it's a concern.

You can actually test it right now, the patch is functional, although you won't have any images (only 2 icons missing).

Please continue to post feedback, I really appreciate it

I don't understand this item in your list:

I can see the usefulness of an edit icon, but the text and defaults don't make a lot of sense to me.

Also, the icons have clear tooltips when hovered, and have alt text for when images are disabled.

To elaborate, I do the following:

1) Go to the course
2) Go to the Gradebook
3) Select "Weights" from the pulldown menu
4) An error page appears with this message:

"require_js: yui_json - file not found."

The reason why you are getting this error is that this patch is against the upcoming 1.9.3 version, which includes new and updated YUI libraries. But you can actually comment out the lines in grade/edit/weights/index.php that start with require_js(), since AJAX is not currently used in this patch (it is there as a stub).

To explain the suggestion that this page prints out the deviations from defaults:

As I see it, the potential of this page is that it can encapsulate all the needed information for one to determine how a grade is computed in Moodle, and preferably without any specialized knowledge of the history of how these features evolved. The display should be self-evident to anyone who is familiar with how students are typically graded.

So, if I have scores and this page, I should be able to sit down with a calculator and compute the same summary statistics that determines the grade.

Showing weights and extra credits is really nice, as is the aggregation method. It does not, however, show multiplicator, offset, keep the highest, or keep the lowest, for example. In most cases these won't vary from the default, so they normally don't need to be displayed. But if something does not seem to compute correctly in the gradebook, the only way to find these issues is to drill into every item. And note that even if these were not applicable, the only way to be sure is to check each one, so it makes debugging the grade computation very difficult.

But you can resolve this by appending a comment to items that don't match the defaults. Then it would be a complete description of how grades are computed on one page, which would be swell.

We patched get_weight_input to check for boolean values of $item (only seen in the empty category case):

function get_weight_input($item) {

if (is_bool($item)) { // Added to workround empty categories.
return '';
}

if ($item->is_course_item()) { return ''; }

and modified the end of build_html_tree with:

$aggcoef_input = get_weight_input($item);

if (!(is_bool($item))) { //added to test for empty categories
$html .= '<span class="gradeitem">' . "\n$aggcoef_input\n{$element['item']->name} (" . $item->get_formatted_range() . ")</span>\n";
}
else { // Formats empty category labels. $html .= '<span class="name">' . $element['item']->name . '</span>' . $aggregation_type . $aggregateonlygraded . $aggregatesubcats . $aggregateoutcomes . $aggcoef_input . $hidden . "</span>\n"; }
}

$html .= "</li>\n";

Again, more of a workaround than a 'proper' fix, but it works!

So, I made a fresh install of HEAD, started a new database and made a new course. Going into the new weight report, I get a Fatal error opening required HTML/AJAX.php.

As suggested in an earlier part of this tracker entry, I commented out line 37 of grade/edit/weights/index.php for the require_js, and I get the same error.

When HEAD is fixed I will again try to test it.

--Gary

I just made a fresh install of HEAD, installed the DB from scratch and created a new course: no fatal error with HTML/AJAX.php. I don't understand why you're getting this problem. Can you try checking out an entirely new directory of HEAD?

I have a few questions/ suggestions about extra credit:
1) Can the points an activity has add directly to a course total for extra credit if they are not in a category?
2) Can a category can be set up completely for extra credit with a checked box? It looks like Interface4 allows only for weights on categories instead of checking a box and saying something like, "this category is only extra credit and can add no more than 5% to a course total."

I wonder about ways to keep the line length as small as possible, to make scanning across lines easier. Would it be helpful to be able to contract column headings from full text to icon to make it more compact? Would the ability to hide columns be helpful? I am thinking of the users that feel overwhelmed and want to limit choices. Or would that lead to more problems of the type, "Why isn't my gradebook working right? Oh, I have a hidden setting wrong."

One suggestion - and not sure if this is the right place for it - if not, my apologies.

When using "weighted mean of grades" for a category, I see no place that the students can see what the relative weights are for each assignment. It would be nice if they could.

As a workaround for my students - I have suffixed each Grade item name with the relative weight in brackets. This allows me and the students to see it - but I have to remember to change it if I change the weighting. It would be nice if this was displayed automatically.

This is a great improvement to the gradebook, well done!

A couple of questions:

1. How do you navigate to the "weights_interface2" page or was that just a proposal?
2. On your testing site, how would you move Semester 2 category to the Testing Gradebook category? At the moment it's the child of Semester 1 and when I click on the edit item the parent category is not editable. Some check boxes next to the categories doing the same as for the grade items would be nice.

1) Replace the "check all" and "check none" links in the Select column for categories. Replace it with a single checkbox and javascript that checks all child boxes and moves the whole category, including parent category container.

2) Alternate to 1) get rid of the select column and moveselectedto buttons at the bottom altogether. There are already ways to move items (the little up/down arrow icon) and effort should instead be put into making this table AJAXy with dragging and dropping of categories and items. Having two or more similar ways to move items around only confuses and makes documentation more difficult in my humble opinion.

3) Overloading the weightsorextracredit column is really confusing in my opinion. It made me think that extracredit was being handled differently in this version, so I can imagine that faculty will think this is really a bad mix-up of meaning. IMHO extra credit needs some serious loving and improvement, but that is a different discussion.

4) Although I have limited/no experience using "aggregate including sub-categories" and it is not immediately obvious to me that it has a real affect on grades anyway. It would seem to me that checking this should gray-out/disable the sub-category aggregation settings (as they presumably don't matter since they are superseded by the parent category) and/or align the child categories to have the same aggregation method, then gray-out/disable all child settings except allow tweaking the weight (if appropriate), offset and multiplier of direct and indirect grade items.

Bugs I found:

1) As stated by Barry Oosthuizen: moving sub-categories (such as "Semester 2" on the test machine) is at best buggy. I tried with both the move icon at the category level and the select and moveselectedto button and neither seemed to be able to move things around reliably.

2) Using the "hide" icon on categories does not gray-out the text for the category or subcategories. It does gray-out direct and indirect child grade items, but not child grade category items.

Overall, this is really great work and I look forward to showing this off to our faculty.

Barry -

1. The weights interface was an early draft of this more complete interface.
2. Moving subcategories is buggy at the moment. But you can successfully do it by clicking the up-down arrow icon (move icon) next to the sub-category, and clicking a target box below the main category, but not the one at the very top. For some reason it cancels the move if you select that one.

Paul -

2. We considered and even tried an AJAX drag and drop version of this. Unfortunately, the way categories and grade items are organised (especially the recursive nesting and cohabitation of grade items with categories on the same level) makes it virtually impossible to design a user-friendly drag-and-drop approach. Consider for example what should happen when you select a sub-category that contains grade items and drag it over another category which itself contains grade items and categories. Consider the empty space left behind while the selection is being dragged, the potential drop targets and the meanings of these drop targets. It becomes a real nightmare.

Because of the difficulty of point number 2, your point number 1 is moot since we need to be able to move a whole bunch of grade items by selecting them one by one (we don't necessarily want all the items in a category, or even items from the same category)

3. Extra credits are an area in which we need further feedback and ideas, your point is noted.

4. "Aggregate including sub-categories" doesn't override the aggregation of child categories, it just means that it uses the "totals" of its immediate child categories in its own "total". If switched off, it will only use grade items in its aggregation.

Thanks for the bug reports, I will look into them after I've finished my review of the LSU gradebook.

1. Extra Credits
I agree with the point over extra credits, it's a bit confusing the way it is at the moment, a separate column for this with tick/untick options would make more sense to me (although I don't use this function so I'm not familiar with it).

2. Column/Page Width
On my little 15 inch screen I have to scroll left and right to find all the columns on the advanced interface. (If I zoom out the letters are too small to read easily). Icons instead of headers?

3. Hide/Show Advanced
In some of the other modules in Moodle you can specify what you want to classify/hide as advanced options. Is it feasible to include that kind of facility here?.

e.g. I only ever need to see the following columns:

Name|Aggregation|weightorextracredit|Range|Aggregate only non-empty grades Aggregate including subcategories|Actions|Select|

This would also solve my problems in point 2.

I guess another option would be to use icons instead of headers.

4. Moving Categories and items
It is needed to be able to move a category with all/some of it's items to become the child of another category. I can't see that it's possible at the moment. Tick boxes next to categories?

5. Bugs
Can't move subcategory to be child of another subcategory using up/down arrows or using editing icon. It only changes the order in which they appear (not who the parent is).

Okay, I sensed that AJAXy stuff was probably a bit too difficult and you confirmed that. However, I would still argue that if you're keeping the "select" column, change the "Check all" and "Check none" links in categories to be a checkbox themselves (which, when checked, automatically checks all child items). This way you still get multiple select, but you can also move categories and their contents the "checkbox way." This allows two parallel and nearly feature identical ways of accomplishing movement. The "icon method" has the advantage of precise placement and the "checkbox method" allows for multiple, but they both can move items and categories. Make sense?

If nothing else the phrase "All/None" is used elsewhere as common lingo – so you could drop the "Check" word for succinctness.

A usability enhancement could be made that indents the "move to" placement box (the dotted line box with an arrow you get when moving items). Currently the boxes are all indented at the same level which makes it very hard to determine if you're moving something into the last spot of category X or after the category (into category X's parent category).

Extra credit is something I have some (big picture) ideas on, is there some active discussion thread/bug where it's future is being discussed or where use cases are developed?

Again, thanks for all the effort.

1) Should the "Include Outcomes In Aggregation" column be included in the table if outcomes are disabled accross the site? (Admin - Grades - General Settings)

2) The placement of the "Category Total" item seems to always directly follow the category name in the categories and items edit view no matter what the setting is under "Course Settings" -> "Aggregate Position". I'm guessing you changed this to help rectify the problems with item movement. I feel this may be confusing to professors/teachers who expect that the order on the "edit categories and items" view is a top-to-bottom oriented list of the items that appear left-to-right at the top of the "grader report." This new view now breaks that 1-to-1 relationship.

3) If the parent category is set to "Weighted Mean of Grades" the two subcategory rows (name and "category total") both have input boxes for weighting. It is not immediately obvious which one should be filled out. I've always personally found this confusing when drilling down to edit either the name or category total and I want to just put in a plug to not have that behavior exposed in this view as well. Teachers will wonder "Do I have to set both?", "What If one says 0 when the other one is set?", "My percentages don't add up to 100%!" So, in essence, could one of these input boxes be dropped? I'd vote for dropping the "Category Total" box as then all the weight setting boxes are at the same level in the tree, though it appears that currently it is unsupported to change the setting via the course name row.

4) Many Warnings are exposed if you choose "Mode of Grades" for a category aggregation method.

Thanks for fixing the buggy category moving.

I second Paul's comment on placement of the "category total". When you move a category to another category you would expect the "move to here" box to be below the category, not below the category total. With the new layout it seems you're dropping the category outside of the other category where you are actually moving it into it.

Paul's points:

1) Yes I will take care of that and use this issue's number in the commit note
2) I'm looking at this now trying to display it in a less confusing manner
3) Not sure about this yet
4), I've filed a new bug for it (MDL-17825), and fixed it immediately.

Robert,

The interface2 interface was the initial draft, but a number of usability problems were popping up which literally crippled it. Here is a summary of them:

1) Due to the limited space next to each category, we had to resort to icons for some of the settings whose name is rather long. Icons with no label violate Moodle's standards unless their meaning is immediately evident, and we could not find adequate icons for all the complex settings of grade categories.
2) Related to the previous item, the recursive hierarchy of categories and items means that, potentially, the settings next to each category and item moves further and further to the right, the deeper we get into the hierarchy. It may look good in the screenshot with a simple hierarchy, but is quite horrible with more complex setups
3) The screenshot displays only a small portion of all the settings available for categories and items. The requirement of putting labels next to each setting would render this interface terribly crowded
4) There is no way to align settings with each other (actions, checkboxes etc.)

As you can see, these issues are all related to visual presentation. The only redeeming quality of this interface is its nice list-type appearance, which at first glance is quite easy to understand. However, if you are happy with the settings presented in the screenshot, you should be able to create a separate report using the patch. The underlying code it depends on should not have changed significantly since 1.9.2.

Regarding the weights/extra credit appearing both for category and total, I think there's either a bug there, or a huge usability error.

• When I set the category to "Sum of Grades", its sub-categories have a checkbox in this new interface, but when I edit the category, I have an "Aggregation coefficient" field, not an "extra credit" checkbox. The category total, however, has an "extra credit" checkbox as expected.

• When I set the parent category to "Weighted mean of grades", both the child categories and their totals have a text input, and when I edit them, they also both have "Item coefficient"! That doesn't make any sense to me. One clue that the category probably shouldn't have this field is that, when you click on the help icon, the help file is missing...

So my guess is that, as you say, Categories should not hold any info about aggregation coefficient. This is the case in the database anyway.

As Bob said, thank you for all of your hard work on this! The ability to assign weights to all categories and/or items on one screen is a big functionality improvement.

I agree with Bob's assessment about the interface: interface2 is very preferable to interface4. The layout is closer to the current layout, which is what our instructors are now used to. As you mentioned, this layout is very intuitive and makes it easy to see what items and categories are nested within other categories.

I agree with you that a string of unfamiliar icons is not the correct way to address this issue. Instead, I would argue that showing all of the category options on a single page is unnecessary and overwhelming. The vast majority of instructors do not need those options, so it would make more sense to me to create a separate report with all of those options instead of jamming them onto the default Categories and Items page.

I have been working with a group of instructional technologists from other institutions on gradebook usability. Here are some usability issues we've found with the current patch (interface4):

1) The "weights and extra credit" column is confusing. There is no visual indication of which text boxes are for weights and which are for EC. I don't think it makes sense to lump these two options together. I would argue that EC does not belong here at all. (As I mentioned above.)

2) There is no visual indication in the weights column of which items/categories are nested inside other categories. It should be effortless to see which items are being weighted against each other; instead, it looks like each item is weighted against everything else on the page.

3) This is a minor cosmetic thing, but the font is larger than necessary, and larger than the rest of Moodle. I have to lower the font size in my browser to avoid horizontal scrolling.

Based on the above assessments, the things we'd like to see on this page are:

1) A more clearly defined tree structure, like the current core C&I interface or the interface2 screenshot. For me, the interface4 layout does not provide this.

2) The only additional options we'd like to see on the C&I main page are the aggregation method and the weight. It is advantageous to be able to set these from a single page because they are interrelated; the weights are relative to each other, so it is necessary to be able to set them on one page. The other settings (e.g. multiplicator) only affect the individual category, so it makes more sense to set those on that individual category's options page.

I understand Gary's desire for instructors to be able to work through the gradebook's calculations to verify that it is set up and calculating correctly. My instructors have been asking for the same thing. However, I don't think the current patch fits the bill, since the instructors would have to have the grader report open separately (or on paper) while they worked through the calculations. Instead, I would propose adding a column to the grader report (with a show/hide toggle) which shows the calculations the gradebook is doing as a formula. This would be much more useful to my faculty.

Thank you again for all of your hard work! I know it's difficult to balance everyone's needs and figure out an interface that works for everyone. We really appreciate what you're doing!

Gradebookweights2.patch appears to do exactly what I wanted to see: it adds the ability to edit aggregation methods and weights for all categories and items on a single page, and it packages it as a separate report called "Weights." I really like this. Instead of editing the original Categories and Items page (as in weights_interface4.jpg), could you package that ability to see all category options on a single page as a separate report? Then people who want that functionality would have what they needed, but instructors who don't need to see all of those options would still have the view they are used to.

~Caroline

Some provoking questions:

A. There are two ways to separate simple from advanced functionality on an all-in-one screen.

1) implement two separate reports in the menu
2) have a simple/advanced button which toggles the view

Which of these do people prefer and why? I'd really like to hear from real teachers about this (admins/developers seem to find it hard to judge)

B. What are simple and what are advanced category settings? Should the Admin/teacher decide this (possibly further complicating the interface) or should it be hard-coded according to some sort of consensus that we reach here?

This addresses Paul's point on weights and extra credits being shown for both categories and their total.

On A), I would choose #2. From a coding perspective I would suspect there would be better code reuse and with #1 there would more likely be code drift/bugs/layout issues. As a faculty trainer, I sense there would be less confusion with an "Advanced" view that exposes more esoteric settings rather than a whole different view that overlaps in many ways – it seems less easy to toggle back and forth with a separate view.

On B), I feel like there is already a reasonable mechanism for setting which attributes are advanced and which are simple (Admin -> Grades -> [ Grade Category Settings | Grade Item Settings ]). I would personally like those two settings pages to be more similar, perhaps with a table that looks like a matrix (looks much better with a monospaced font, but I see no way to force that here):

<pre>
========================= Grade Category Settings ==============================

Default Advanced Force
Aggregate only non-empty grades: [______] [] []
Include outcomes in aggregation: [______] [] []
Aggregate including subcategories: [______] [] []
Keep the highest: [______] [] []
Drop the lowest: [______] [] []

=========================== Grade Item Settings ================================

Default Advanced Force
Item info: [] []
ID number: [] []
Grade type: [] []
Scale: [] []
Minimum grade: [] []
Maximum grade: [] []
Grade to pass: [] []
Offset: [] []
Multiplicator: [] []
Grade display type: [] []
Overall decimal points: [] []
Hidden: [] []
Hidden until: [] []
Locked: [] []
Lock after: [] []
Aggregation coefficient: [] []
Parent category: [] []
</pre>

Then, the categories and items page needs to respect the "advanced" flag and "force when hidden" flags to build the simple, and advanced pages.

For our environment: simple would include columns: Name, Aggregation Method, Range, Drop the Lowest, Actions, Select.
Clicking advanced would show everything except: Include Outcomes in ... as we don't use outcomes at this time.

http://test.moodle.org/1.9/mockup.html

While I'm not a huge pastel fan I do think the color and indentation mechanism really increases immediate knowledge of encapsulation/levels. The current color scheme with each depth a different color shows depth, but does not differentiate between siblings (for instance between "Subcat 1" and "Semester 1" in the mockup.html link). Maybe not a big deal, but something I thought of when looking at this. Perhaps each level is a hue and then each category at that level alternates saturation or has a cross-hatch transparent png background image for better color-blind accessibility?

One of the places where I would see understanding depth and category levels as very important for accuracy is in assigning weights (as per Caroline Moore's #2 point above). Perhaps the same CSS/styling used to differentiate between depth and siblings could also be placed right next to the weight field? Or perhaps an onfocus event on the weight field might highlight all the other weight fields in the category at the same depth)?

Great work! Having made the switch from 1.8 to 1.9, these updates and changes are tremendous in getting accustomed to the gradebook.

One thing we see from our end is a need to have grades calculate above 100 percent. If you add an offset of 10 points, then those students who have 100 do not get this "bonus". If the student was a solid 100% for the entire category, this would not effect the overall percentage for that category, but for those students who need these points to help pull there grade up, having the grade book calculate the 105's or 110's would be helpful. Or maybe I'm just missing something all together. Thoughts?

Your hard work is appreciated by all!

"Although my biggest complaint with moodle is the number of screens (and
hence clicks) necessary to get things done, I have to admit I like the
first (weights_interface2.png), stand-alone screen much better than the second collapsed/expanded
option (weights_interface4.png). It is much easier to see the overall structure of course
assignments in the first view and to understand that weighting is being
done for each category not for items within a category."

http://test.moodle.org/1.9/grade/edit/tree/index.php?plugin=tree&id=2

username: teacher
password: testm00dle

I especially like the fact that you got rid of the category totals altogether when moving categories. Much easier to navigate this way.

The vertical lines combined with the pastel colours on the non-advanced screen are also very helpful. Sometimes there is a line missing though. Sometimes it's missing on the advanced screen and sometimes on the simple screen.

Paul, thanks for your ideas and comments, I have implemented most of them in the latest version on test.moodle.org.

Courtney,
I would be grateful if people who offer feedback would do so using the test site instead of the screenshots. There really is no way to know which interface is better just by looking at the screenshots. The ones your professor looked at were out of date, so the usefulness of his comments is reduced, unfortunately.

Brian,
Although it is a fairly common request, I have never understood the logic of allowing points above a maximum, when you simply need to decide not to grade your students above a certain (informal) maximum, then use the grade item's real maximum to allot extra points.
That being said, we are looking at ways to implement something like this in 2.0, but it will not be backported to 1.9, because that would require changes to the database structure, which is not allowed for released versions.

Regarding the colours:
Currently colours are based on the depth of the categories. This is the simplest method, and it can easily be overridden by editing the style sheet. Assigning custom colours to each different category would require a new database field, so it's not feasible in 1.9, but we can certainly look at it in 2.0 if there is sufficient user demand for it.

The colors really do add a lot to improve things.

The only bug I found was that when moving a single item using the icon and placement box method, it appears to me that the placement box for the last spot in category is not indented appropriately and is actually on the same indentation level as the next placement box which is after the category.

I'm guessing the remaining things I'd like to see addressed would require a DB change, and thus would only be considered for 2.0 if at all...

1) break apart weights and extra credit column as in comment on 06/Jan/09
2) modify and obey the grade_item and grate_category settings as in comment on 09/Jan/09 part B

The only nitpicky additional comments I have are that some columns wrap when they shouldn't have to; As I see it the Name and Range columns should have a no-wrap CSS property (white-space:nowrap or at least be allowed to expand the table as necessary and all the other fields have a predictable maximum width (at least in terms of em). The Actions column wraps with not enough space for more than 5 icons (I have up to 6). The overall width of the table should be allowed to fill all my screen real estate if necessary.

Again, things look really good. Thanks a ton!

I've fixed the placement box bug which you just reported, and implemented the excellent suggestions you gave regarding CSS and presentation. You're correct about items 1 and 2 though, we'll need to wait for 2.0 for these. Thanks again for your time and feedback.

Apologies if I'm missing something totally obvious, however I was wondering how you can edit the course total, or any of the category totals, say if you want to set ID numbers?

Something else I was wondering about, was the "Drop the lowest" and "Keep the highest" fields. I can't find them on the edit category pages. Is that intentional?

1. The current method: All columns are considered advanced except Name, Actions and Select. No setting can change this, it is hard-coded.

2. Use the "Advanced settings" already in place at the site level (Site admin -> grades -> Grade (item|category) settings), as suggested by Paul Ortman in this discussion (09/Jan/09 11:43 PM). This gives us more flexibility, without adding much complexity to usability. Another advantage is that it requires virtually no additional coding.

3. Add a site-wide configuration page just for this interface, with grade category and grade item settings combined, in which advanced settings can be selected independently of the other gradebook pages. This is not very complex to create or to use, and is slightly more flexible than option 2

4. Create a "preferences" page for this interface, where advanced columns can be configured per-course and/or per-user. This is significantly more complicated, since it adds yet another page of parameters. The advantage is that it is very flexible.

Please test the current interface (using option 1) at http://test.moodle.org/1.9/grade/edit/tree/index.php?id=2 (username teacher, password testm00dle), and give your feedback here.

Thanks

I think the goal of this configuration page should be that one does not need to drill down into things to determine how a final grade is computed, and that straight-forward grading strategies should be uncluttered.

So, what I would do is add the "aggregation" method to the standard view, as well as the weight and the range. The weight should be grayed out for those methods that don't employ them (then teachers will discover how to use weights by changing the aggregation method). These three properties additional properties are essential for deciding how a grade is determined, so they are not "advanced" in my view.

The other settings could be advanced, but to allow the grading strategy to be fully revealed in the standard view, when the settings don't match the defaults, there deviations from the default should be printed as a string in 9 point type below the aggregation method.

The test to see if this is effective is that one should be able to view this page in either standard or advanced mode, be able to plug in some values, and to be able to perform the arithmetic by hand and come to the same final score. Ideally this could be done by someone not familiar with Moodle. The above suggestions move us at least to it being able to be done by somebody fully familiar with the Moodle gradebook (and advanced Moodle teacher or experienced administrator or trainer.

We should see if we can reach a consensus (if there is not already) on "reasonable defaults" for these settings, and allow for for them to be changed by institutions using the #2 option as suggesed by Paul Ortman, recognizing that most institutions won't make changes.

Extra credit should be a checkbox, but it can be an advanced option, provided that when it is selected the standard view shows it is enabled with the "small type" feature I described above. I understand how it is internally implemented, but that implementation detail should be hidden from users. Perhaps the checkbox should put a 1 in this field, but the weight does not display 0 or 1, but allows for a different value for 1 to be entered to maintain its current ability to serve as a multiplier (I doubt many people use it that way).

Those are my main comments on this particular implementation, and I agree with others that this is all a step forward.

To be complete, I would also repeat some of my previous suggestions:

• Gradebook configuration should be a tab in the grader report. Having it be one of the dozen items in the gradebook report makes it too difficult to find.
• Extra credit should be implemented in other aggregation methods. I have discussed in other tracker reports how we have implemented that at Seattle Academy, and it does not require a database update. Extra credit is the standard method for a teacher to recognize non-required work and exceptional performance and to correct for disappointing performance early in a course, so it should not be too difficult for a teacher to do.
• Naming of "Aggregation" and these summary methods should be reconsidered as I think these are not self evident.

--Gary

Do you have some suggestions regarding better names? Please believe that we (at least 10 of us) have racked our brains and spent hours discussing these terms, trying to find the most descriptive (and short) words. If you have some better suggestions, please share them in a forum discussion so that other users can also share their opinions.

2) I have a suggestion regarding colors for weights.
Right now Category Totals are white. I would recommend to make them the same color as the color of the category, so visually people will see that Total is not just another item on the list.

3) Btw, I find words "Grader report" to be confusing. For me Grader - is the person who grades.
I suggest something like this:

View Reports:

• Grade Roster <aka Grader>
• Outcomes <Outcomes>
• By User <User>
• My Grades <Overview> - I would put this one to be the last one
  I will post this to the forum, since I have not fount an item in tracker for this.

Thanks

Gary, thanks for your comments. Apologies again if I'm missing something obvious, however I'm just wondering why a column showing ranges is necessary on the edit categories and items page?

The reason that range should be in the standard view of the gradebook configuration page would be in keeping with the principal that one should be able to do a hand computation of the total grade by looking at this page and assigning values to individual activities. One would need to know how many points is possible for an assignment to compute the overall grade.

Nicholas:

As a starting point for discussion, these terms have been more self-explanatory to my fellow teachers and students. But I made these arguments when 1.9 was in Beta.

Old name-> New name (explanation)

Aggregation -> Summary method
Weighted mean of grades -> Weighted grades (weights can be applied to categories or activities)
Mean of grades -> Average of percentages (items are converted to a percent and then averaged)
Simple weighted mean of grades -> Average of points (The grade is the total points earned divided by the total number of points possible)
Mean of grades (with extra credit) ->[commented out] (We don't use this as we allow activities to be extra credit and/or go over the assigned maximum)
Mode of grades -> [commented out] //causes clutter, complexity, and confusion
Sum of grades -> Total of points (The grade is the number of points earned)

Re. renaming terms, please post in the gradebook forum, as Nicolas suggests, as this tracker issue is already extremely long!

Elena, it would be great if you could post in the forum too.

1. Grade category settings that are forced are shown in plain text (not user input possible), or hidden entirely if the setting "Hide forced settings" is on.

2. Grade item and grade category settings that are advanced are hidden from the "normal" view

The main limitations of this method are that regular teachers cannot change these settings, and that they apply equally in all courses.

I can't do a whole lot more playing around testing the various settings as I only have teacher access on the test site. Is this code checked in somewhere so I could test on my own box?

Gary, I really like most of your terminology suggestions and I clearly need to figure out how you did your extra credit improvements as we have quite a bit of demand for that at our institution.

You may want to repost an admin password (or at least a course creator password) so we can set up our own courses. The one course I made I can no longer access. Given that you can reset the database if there is any funny business, I don't think this would be too big a risk. As an alternative, you could email them to those of us commenting.

But it would be nice to have more realistic courses to test these with; most courses will not be complicated, just a little different.

As we just chatted about, here is a graphic of how to add exceptions to this page using a small font type so that a grade can still be computed in either view if scores are given.

Also, I point out where max can be added and suggest that extra credit not be labeled here; it should be a checkbox in advanced view.

Long wordings are a problem and I will suggest those in my sample course.

1) The title tags on the item names and icons should not be the item name, they could be just the item type (eg "Assignment") which would be useful when you hovered over them.

2) Default colours should be colour-blind friendly - don't put green and blue together.

Thanks to everyone who voted. The new 'Edit categories and items' page will certainly be part of our gradebook improvements http://docs.moodle.org/en/Development:Gradebook_improvements

Watchers, thanks for your interest. You may wish to watch MDL-16913 from now on.

Martin, thanks for your suggestions, which I've added to MDL-16913 as subtasks.

http://docs.moodle.org/en/Edit_categories_and_items

I'm just removing 2.0 fix version as the instructions state 'Do not include the current HEAD version unless it's the only one.'