Outcomes

Support for Outcomes (also known as Competencies, Goals, Standards or Criteria) means that we can grade things using one or more scales that are tied to outcome statements. It is intimately connected to Grades but is optional to use.

For example, an assignment might be graded according to these three scales (together known as a Rubric).

Content - Poor, Fair, Good
Organisation - Poor, Fair, Good
Grammar - Poor, Fair, Good

These are the components:

Site vs Course outcomes

Most outcomes are made available at the site level, which means they can be used by any activity in any course, provided the overall switch is on. This is achieved by leaving the outcome's courseid field empty (in the database).

In some cases you may want to define a special outcome, specific to a particular course. This is achieved by assigning the course ID number to the outcome's courseid field. Such an outcome is NOT available outside the context of that course.

Overall switch

The admin has a site-wide switch to enable/disable outcomes completely for the site.

Outcomes management and reporting

A grade report at /grade/report/outcomes is the place where people manage outcomes. There are three tabs to this report, visibility is dependent on your permissions:

Site management (Admin user)

The admin can create and edit a list of outcomes using a GUI.

Outcomes have these main fields:

• shortname - some code or abbreviated name
• fullname - the full "sentence" describing the outcome
• scaleid - a chosen scale for ratings

Later we can also add importing from a CSV file, so that it's easy for sites to import long lists of state-based standards or training competencies.

Course management (Editing teacher)

The editing teacher can choose from this large list to pick a subset of outcomes for the current course. They can also define new outcomes to be used JUST for this course.

Course reporting (Teacher)

The course report displays all the chosen outcomes for this course along with information about which activities are currently tied to them, or reporting of students according to which outcomes they've achieved "passing grades" in, and which ones they are failing in, as an aid to identify strong/weak points for individuals and groups.

Here is a sample report:

Outcome name	Overall average	Site-wide	Activities	Average	Number of grades
intelligence	Idiotic (1.5)	No	Philosophy in France	Idiotic (1.5)	2
Wisdom	Smart (4.29)	Yes	Ancient Gaul	Stupid (2.6)	5
			French Kings and Queens	Clever (5.97)	2
honesty	-	Yes	-	-	0
Arrogance	-	Yes	-	-	0

Activity editing

A new grading section added to the course mod update form using a single function (similar to standard_coursemodule_elements()) which offers a choice between:

• basic grading (as now) OR
• outcomes

The course outcomes are shown in a multi-select list and any number can be chosen.

For Moodle 1.9 we should not offer both, to keep things simple.

The result of these forms goes to course/mod.php which is able to process them without any further functions from the module itself. Roughly it would use grade_get_items to find out what items were already set, and then compare to the new form input to work out what calls to grade_update() need to made to create/update/delete existing grade_items.

Note that not all activities could be upgraded to support this. Assignment is a natural first one to implement for 1.9, then we can see after that.

Potentially even modules without grading could still support outcomes, the columns in the gradebook would just have to be filled in manually, that's all.

Activity grading

Activities that support grading (like Assignment) need to be upgraded to support:

Multiple grading interface

grade_get_items() would get the items and make the interface fairly easy to do. Where there was one popup menu there would now be multiple popup menus.

Storage of multiple grades

This is a bit more tricky, because we want to avoid adding lots of grade1, grade2, grade3 fields to every module's tables.

I can see three potential ways forward here:

1. We add new fields to every module and just live with the hardcoded limits (eg max of 5 outcomes per activity).
2. We add a new generic table where modules can store their grades (outside of the gradebook).
3. We open up the API slightly to allow modules to store their grades directly into the gradebook. This sort of binding was something I have been always trying to avoid but perhaps it's unavoidable.

We need to discuss these options and think about them some more.

Some example scenarios: Outcomes_examples