As this is my first post to the Moodle forum I thought I’d preface this with a quick hello and a little about me. My name is Evan and I’m a software developer working for the University of London Computer Centre (ULCC). We’re a big Moodle user, hosting over a 100 installs for various universities, colleges, workplace training providers, and the NHS. We also do a lot of work developing custom modules, and host our own Moodle conference “Moodle Wonderland” as well as soon to be hosting “MoodleMoot UK 2010”.
It’s come to my attention recently that the current implementation of scales in Moodle leaves a bit to be desired. Specifically in regard to being able to assign arbitrary numeric values to non-numeric scale items. I’m confident that we are all familiar with grading schemes where letters or words map to numeric values (e.g. D = 50%, C = 60%, B = 70% and A = 80%), however Moodle has somewhat limited support for this.
At present if I were to create a scale of say (D, C, B, A) those scale items would have numeric values somewhat different to what one might intuitively expect.
If I were using the normalized aggregation method the scale would be:
• D = 0/3, C = 1/3, B = 2/3, A = 3/3
However if I were using the sum aggregation method the scale would be:
• D = 1, C = 2, B = 3, A = 4
Alternatively, if I were using LSU scales with the normalized aggregation method the scale would be:
• D = 1/4, C = 2/4, B = 3/4, A = 4/4
Regardless of the aggregation method, the general lack of control over how scale items are converted into numeric scores for the purposes of the Gradebook makes working with scales rather frustrating. Indeed I am hardly the first person to notice this (see forum posts 106031, 120541, and 130707 for various other people's comments).
One way I have seen suggested to achieve a desired mapping of scale items to values is to pad the scale with additional placeholder options (see Helen Foster’s comment on this topic)
For example a scale of (-, -, -, -, -, D, C, B, A, -, -) would, when using the normalized aggregation method, equate to a scale where D = 50%, C = 60%, B = 70% and A = 80%.
This hack has two main problems: firstly it introduces bad scale options into the database, which if accidentally chosen would have undesired results in grade calculations; and secondly the number of additional placeholder options could become prohibitively large in scales where there is a larger number of elements or less regular offsets between them.
It strikes me that the only way around this problem is to change the current database model to allow the assignment of arbitrary numeric values to each element of a scale. A ticket on the tracker, MDL-17258, requesting just this has been around for over a year now and at present it has 22 votes, placing it in the top 50 most voted for tickets. Unfortunately, despite the strong community desire for this change it has not made it into the roadmap for Moodle 2.0.
As this issue negatively impacts on a larger project I am currently working on I propose to make the necessary changes myself and post the patch back to the Moodle core developers who doubtless have their hands full at present with all the other exciting changes that are currently taking place in Moodle.
At this stage I am interested in suggestions from the community about what other changes to scales people might want. My primary goal is to resolve ticket MDL-17258, however I also see no reason not to resolve ticket MDL-13372 at the same time. Presumably, but adding this functionality it would also obviate the need for ticket MDL-18881?
What else would people like to see happening with scales?
I just noticed another problem with the current implementation of scales. Because they are stored as comma delimitered values (CSV) it is not possible to have a comma in the scale name, which is apparently an internationalisation issue in German and presumably other languages also.
The need for this has been largely dealt with in MDL-17484 with a patch for 1.97 supplied.
Hey Bob,
Thanks for the update, I overlooked that ticket in the tracker. I've just had a look at the patch you posted, and whilst it's a nice compact solution, it's only useful in a rather narrow way.
What you appear to have done is solved the request discussed in ticket MDL-18881, which asked for a direct mapping between the `grade_letters` and `scale` tables. This is fine when you are only using one scale in your course and that scale is the same as the letter grades you are using in that context; however this breaks down when you are using outcomes.
Imagine a bunch of outcomes all attached to the same course, but with different scales. In this scenario doing a simple string comparison between the name of the scale item and the name of the letter grade is not going to work.
Regards,
Evan.
Thanks for the update, I overlooked that ticket in the tracker. I've just had a look at the patch you posted, and whilst it's a nice compact solution, it's only useful in a rather narrow way.
What you appear to have done is solved the request discussed in ticket MDL-18881, which asked for a direct mapping between the `grade_letters` and `scale` tables. This is fine when you are only using one scale in your course and that scale is the same as the letter grades you are using in that context; however this breaks down when you are using outcomes.
Imagine a bunch of outcomes all attached to the same course, but with different scales. In this scenario doing a simple string comparison between the name of the scale item and the name of the letter grade is not going to work.
Regards,
Evan.
Oh yeah, and the other issue with using letter grades is the annoying lack of support for decimal places. At present letter grades can only be matched to integers, see ticket MDL-20367.
It seems there is also a need for a page linked to from the scales administration page that shows the current usage of a given scale.
There are a lot of forums posts from people wanting to delete scales that have previously been used (see 73806, 110784, 134118, 135232 for a few examples). Understandably any scale that is currently attached to a course/activity etc, should not be deletable. However, finding the list of where a scale is used, so you can unlink that scale and ultimately delete it, is exceedingly time consuming without an understanding of SQL and direct access to the database.
This issue could be quite easily solved with a new page, linked to from the “Used” column in the scales administration page, which shows every context in which a scale is used.
There are a lot of forums posts from people wanting to delete scales that have previously been used (see 73806, 110784, 134118, 135232 for a few examples). Understandably any scale that is currently attached to a course/activity etc, should not be deletable. However, finding the list of where a scale is used, so you can unlink that scale and ultimately delete it, is exceedingly time consuming without an understanding of SQL and direct access to the database.
This issue could be quite easily solved with a new page, linked to from the “Used” column in the scales administration page, which shows every context in which a scale is used.
I’ve now created a rough draft of the proposed changes to scales, available at Development:Scales.
Some feedback would be great
Some feedback would be great
We, here, also vote for this functionality. This would also help greatly with possible use of Outcomes as real calculated grading rubrics.
I would be happy to participate in any testing (if you will give me online access to the testing environment
).
However, it would be nice to get a green light from Martin or Andrew. (Andrew, are you the new gradebook developer?).
If it would not make it to the core, or at least agreed to be considered, it will be less useful for the community. We, for example, will never apply such huge patch if it is not in core. Too much of a risk and deviation.
I would be happy to participate in any testing (if you will give me online access to the testing environment
However, it would be nice to get a green light from Martin or Andrew. (Andrew, are you the new gradebook developer?).
If it would not make it to the core, or at least agreed to be considered, it will be less useful for the community. We, for example, will never apply such huge patch if it is not in core. Too much of a risk and deviation.
Thanks Elena, calculated grading rubrics are exactly what we’re aiming for.
I’d also like to get a green light from either Martin or Andrew before I start work on this, as we don’t think it’s worth doing if there’s not at least in principle approval of the change. Changing the gradebook would be a lot more work than just implementing a custom table in our application that stores this additional data, but we’d rather that the grades for our block not be out of sync with the gradebook.
Hi Evan. I think there's some overlap here with what I might be doing to the ratings.
http://docs.moodle.org/en/Development:Ratings_2.0#Migrating_Scales
http://docs.moodle.org/en/Development:Ratings_2.0#Scale
Your proposed solution goes a lot further to improve custom scales. As part of the ratings work I was just intending to make numeric scales work in a less unusual way.
Do you have any ideas on the best way to handle numeric scales in your proposed system? We don't really want to have to create 50 items in scale_items to allow something to be rated 1-50.
I'll bring this thread to Martin's attention. What you're proposing sounds like a good idea. We just need to make sure we're not stepping on each other's toes
http://docs.moodle.org/en/Development:Ratings_2.0#Migrating_Scales
http://docs.moodle.org/en/Development:Ratings_2.0#Scale
Your proposed solution goes a lot further to improve custom scales. As part of the ratings work I was just intending to make numeric scales work in a less unusual way.
Do you have any ideas on the best way to handle numeric scales in your proposed system? We don't really want to have to create 50 items in scale_items to allow something to be rated 1-50.
I'll bring this thread to Martin's attention. What you're proposing sounds like a good idea. We just need to make sure we're not stepping on each other's toes
Hi Andrew,
Thanks for having a look over my proposal and offering to bring it to Martin’s attention. Much appreciated.
My feeling is that numeric scales should be treated exactly the same as non-numeric scales, to reduce complexity in calculations. Creating them however, could be simplified with an extra option in the form. You could either add a scale item one at a time (ideal for non-numeric scales), or you could give a start point, end point and floating-point increment and it would bulk create the scale items for you.
Once the scale items are created you’re then free to fiddle with them as you see fit (e.g. add or remove some items, change the name or value of an item, add an individual description, change the sort order, etc.). I can imagine some users might want numeric scales with irregular increments (e.g. 0, 1, 2, 3, 5, 8, 13, 21, 34, etc.) or where the increment is a decimal (seemingly not possible with your min/max suggestion, at least without adding another field).
- Evan
Thanks for having a look over my proposal and offering to bring it to Martin’s attention. Much appreciated.
My feeling is that numeric scales should be treated exactly the same as non-numeric scales, to reduce complexity in calculations. Creating them however, could be simplified with an extra option in the form. You could either add a scale item one at a time (ideal for non-numeric scales), or you could give a start point, end point and floating-point increment and it would bulk create the scale items for you.
Once the scale items are created you’re then free to fiddle with them as you see fit (e.g. add or remove some items, change the name or value of an item, add an individual description, change the sort order, etc.). I can imagine some users might want numeric scales with irregular increments (e.g. 0, 1, 2, 3, 5, 8, 13, 21, 34, etc.) or where the increment is a decimal (seemingly not possible with your min/max suggestion, at least without adding another field).
- Evan
Evan, we support 100% And Andrew, thank you so much for looking into this!
In my mind interface should look like bunch of entry fields:
Item name in a scale - Number of corresponding points
Good - 5
Average - 3
Poor - 0
Cheated - -10
[Save]
Yes to decimals and to irregular increments.
I have mentioned it previously, but this would later make real use of outcomes as grading rubrics, that so many people want. At least here
In my mind interface should look like bunch of entry fields:
Item name in a scale - Number of corresponding points
Good - 5
Average - 3
Poor - 0
Cheated - -10
[Save]
Yes to decimals and to irregular increments.
I have mentioned it previously, but this would later make real use of outcomes as grading rubrics, that so many people want. At least here
Ill bring this up at today's developer meeting. Hopefully we can figure out what should be done with the ratings and scales work.
I don't understand why you need both value and sortorder columns in the scale_items table. When would you ever want a scale that is not in numerical order?
Hi Tim,
Thanks for taking a look at this
When I was looking at how scales were implemented, and poring over the forum for what other people had said they wanted, I tried to cast as wide a net as possible in recording everything that scales were not currently able to do.
Having a sortorder field is pretty low priority IMHO, but I can imagine a couple of scenarios in which it might be considered useful.
1. A user may want to present their scale as “A,B,C,D” rather than “D,C,B,A”.
2. Items in the scale may not have unique values, in which case it would be unclear which item should be displayed first. For instance I might have a scale with the following items: “Never”, “Almost Never”, “Sometimes”, “Almost Always”, and “Always”. For the purposes of calculating the numeric grade I might not care about the distinction between “Never” and “Almost Never” so they might both have a value of zero. I would however, want to maintain the logical ordering of these items.
Thanks for taking a look at this
When I was looking at how scales were implemented, and poring over the forum for what other people had said they wanted, I tried to cast as wide a net as possible in recording everything that scales were not currently able to do.
Having a sortorder field is pretty low priority IMHO, but I can imagine a couple of scenarios in which it might be considered useful.
1. A user may want to present their scale as “A,B,C,D” rather than “D,C,B,A”.
2. Items in the scale may not have unique values, in which case it would be unclear which item should be displayed first. For instance I might have a scale with the following items: “Never”, “Almost Never”, “Sometimes”, “Almost Always”, and “Always”. For the purposes of calculating the numeric grade I might not care about the distinction between “Never” and “Almost Never” so they might both have a value of zero. I would however, want to maintain the logical ordering of these items.
It would be vastly easier to use (and implement) if we just order the scale items in the UI by value and provide the ability to choose to have them ordered ascending or descending.
That solves the issue of a,b,c,d Vs d,c,b,a. Also, UIs where you have a list of things and you use down and up arrows to individually order them are a pet peeve of mine. They're error prone and require lots of mouse clicks.
That doesn't resolve what to do if the user creates multiple scale items that have the same value. It seems to be a slightly illogical thing to want to do. If I dont care about the distinction between two items then why have two items? That said I'm not sure we can just prevent people from doing it.
That solves the issue of a,b,c,d Vs d,c,b,a. Also, UIs where you have a list of things and you use down and up arrows to individually order them are a pet peeve of mine. They're error prone and require lots of mouse clicks.
That doesn't resolve what to do if the user creates multiple scale items that have the same value. It seems to be a slightly illogical thing to want to do. If I dont care about the distinction between two items then why have two items? That said I'm not sure we can just prevent people from doing it.
Just sat down with Martin to discuss this. We've got the go ahead once we work out these last few bits and pieces. I'll remove the scales refactoring from the ratings work so we concentrate our efforts in one place and this looks like a comprehensive solution to fix a whole raft of scales related problems.
Regarding ordering rating items Martin suggested alphabetical as a sort order option in addition to ascending and descending (by value).
I just noticed that there is time modified in both scale and scale_item. Will the time modified in scale be set every time any associated scale item is modified? That way it would represent the last modified time of the scale item set as a whole which seems logical.
Also, we'll need a rough idea of how long you think this will take? I don't know what else you have on your plate and we need to have some idea where this will fit into the overall moodle release schedule.
Regarding ordering rating items Martin suggested alphabetical as a sort order option in addition to ascending and descending (by value).
I just noticed that there is time modified in both scale and scale_item. Will the time modified in scale be set every time any associated scale item is modified? That way it would represent the last modified time of the scale item set as a whole which seems logical.
Also, we'll need a rough idea of how long you think this will take? I don't know what else you have on your plate and we need to have some idea where this will fit into the overall moodle release schedule.
That’s good news regarding your chat with Martin 
I’m happy to go with the three sorting options you mentioned, as there doesn’t seem to be any compelling reason to put a sortorder field in there. I just spent a little while googling for a scale where items are deliberately out of numerical order and couldn’t find anything. If anyone else knows of one now’s the time to mention it.
In terms of making some time estimates I’ll need to have a couple of meetings with my colleagues to sort out priorities with our current workload.
How should we manage communication between each other? Should it all go through the forum here, or should I email you directly?
I’m happy to go with the three sorting options you mentioned, as there doesn’t seem to be any compelling reason to put a sortorder field in there. I just spent a little while googling for a scale where items are deliberately out of numerical order and couldn’t find anything. If anyone else knows of one now’s the time to mention it.
In terms of making some time estimates I’ll need to have a couple of meetings with my colleagues to sort out priorities with our current workload.
How should we manage communication between each other? Should it all go through the forum here, or should I email you directly?
very excited to hear all of this.
So, this work will allow the "assignment of arbitrary numeric values to each element of a scale" as you've mentioned before, correct?
This is so great.
So, this work will allow the "assignment of arbitrary numeric values to each element of a scale" as you've mentioned before, correct?
This is so great.
Elena, yes it will.
Evan, I've just picked one of the numerous tracker issues to be the official tracker issue for this work. http://tracker.moodle.org/browse/MDL-17258 I've linked in other issues so we can keep track of them all. "Scales don't work right" is in tracker a bunch times.
Once we've got something somewhat working we'll start posting patches in MDL-17258 for others to have a look at. I'm sure that will generate discussion. We probably don't need to preface that with our back and forth so until then email is probably best.
Evan, I've just picked one of the numerous tracker issues to be the official tracker issue for this work. http://tracker.moodle.org/browse/MDL-17258 I've linked in other issues so we can keep track of them all. "Scales don't work right" is in tracker a bunch times.
Once we've got something somewhat working we'll start posting patches in MDL-17258 for others to have a look at. I'm sure that will generate discussion. We probably don't need to preface that with our back and forth so until then email is probably best.
YAY!!!!
Another one off the to-do list!
Another one off the to-do list!
Hi Evan. How are you going? Can you please message me with your email address
Hi Evan,
I need to make some scales & letter grades related changes for our institution, so I was wondering if you have any progress related to yoru proposal?
Oksana