Progress tracking

Note: This page outlines ideas for the Progress tracking feature planned for Moodle 2.0. It's a specification under construction! If you have any comments or suggestions, please add them to the [comments].

Introduction

This feature will allow tracking of the progress of each student, displaying what has been achieved and what is still to be achieved.

There are two ways to do this: by course and by competency:

1. Showing progress by course is pretty obvious and can work on any Moodle site: we just list the courses that have been completed and some courses that are still to be done. The completed courses can show the final grades and the date completed. Courses which are not yet completed can be shown with dates of when they start (if courses use a 'weekly' course format) or shown with the text "not yet completed". In Moodle 2.0, the course completion feature should also allow courses to be shown as either completed or not yet complete (see Course_completion).
2. Showing progress using competencies requires the Outcomes features in Moodle 1.9 to be enabled and used across the whole site. When outcomes are enabled, we have a way of saying "these courses and these activities are intended to achieve these outcomes" and teachers can grade students against those outcomes. The progress report can then show a list of outcomes as past achievements and future goals for each user.

Definitions

Outcome : Outcome is a statement about knowledge that learners get and it may relate with a scale

Eg : “Ability to catch a ball”

Scale : Measurement of outcome

Eg : Bad, Good, Excellent

Required grade : The minimum grade that is needed to deem a competency

Actual grade : The grade a learner obtained for an outcome

Skill : An outcome and the corresponding grade a learner obtained

Eg : Ability to catch a ball  - “Bad”

Competency : An meaningful ability a learner gets when achieve one or more skills with required grades in a context.

Eg : 
In a context, admin may define a competency as “Ability to play cricket” 
and also may define that, to achieve the competency  learner should get following skills with given required grades.
“Ability to catch a ball” – good
“Ability to throw a ball” – good
“Ability to swing a bat” – good.
If a learner obtained good, bad, excellent respectively for the above three outcomes, then the learner fails to get “Ability to play cricket” competency, 
or the learner does not have ability to play cricket in that context.

Goals

1. Allow "admins" to devise a learning plan for an individual user. This can be either in terms of "courses" or "competencies".
2. Allow "admins" to develop a learning plan template. This can also be either in terms of "courses" or "competencies".
3. Allow "admins" to assign a learning plan from a learning plan template to an individual a user or a group of users. This assignment can be made manually in one action (similar to role or group assignments), or automatically using methods such as external databases or parsing text files containing data.
4. Allow "admins" to adjust an individual learning plan for a user, including a portion previously assigned from a learning plan template.
5. Allow "admins" to assign a due date for completing each "course" or "competency".
6. Allow "students" to see their own individual learning plan and their current progress along it (showing what is: done; in progress; or not done).
7. Allow "admins" the ability to see different reports for this data and answer questions like "how many people fit this profile" or "what is everybody working on right now?" or "which people haven't met this competency"?

General architecture

Most of the scripts will be in a top-level subdirectory called "track". This directory will have a similar structure to the grade subdirectory, with plugin support for reports, import and export plugins.

Course-based progress tracking

1. Each user can have courses linked to them (past, current and future).
2. For each course, we look if the course is finished or not.
3. Finished courses are show as "Done", with final grade
4. Unfinished but currently-enrolled courses are shown as "In progress"
5. Other courses are shown as "Not done yet" and will be done in the future

Competency-based progress tracking

1. Each user can have outcomes linked to them , with a required level of competency (grade) for that outcome
2. For each outcome, we look at completed courses to see what grades they have
3. These are aggregated in some admin-defined way (Mean? Maximum?)
4. Outcomes with high grades are show as "Done", with final grade
5. Other outcomes in currently-enrolled courses are shown as "In progress"
6. Other outcomes are shown as "Not done yet" and will be done in the future. They can be used to suggest further courses by matching outcomes.

Learning plan

1. Each user can have a set of either courses to be completed, outcomes to be completed, or a mixture of both. These comprise an individual user's learning plan.
2. Due dates for course completions and outcome completions can be assigned in an individual user's learning plan.
3. A comment can be added to a user's learning plan item when a course or outcome is manually added or removed from it.

Learning plan template

1. Each template can contain a set of courses to be completed, outcomes to be completed, or a mixture of both.
2. A course or outcome can be assigned to a learning plan template (using an interface similar to assigning a user to a role or group).
3. A course or group of courses can be selected for a template from a list of all courses (by drilling-down category/sub-category) or from the results of a search (by course name or course description). Since outcomes are defined within a course, an outcome or a group of outcomes can be selected from a list of courses or search result.

Requirements

• We'll need to access and use the existing site-wide Outcomes Outcomes tables

• We'll need to use the tables that indicate completion status for courses (these are not yet in place) Course Completion

• We need to get aggregate information about the course outcomes and aggregate grades for each user from the gradebook API

Standards support

Moodle should support global standards in order to enable importing and exporting of competency information. IMS specifications will be used on this matter. IMS RDCEO (IMS Reusable Definition of Competency or Educational Objectives) will be used to capture the competencies/educational objectives and IMS LIP (IMS Learner Information Package) will be used to model the user profiles and their competencies.

IMS RDCEO

IMS Global Learning Consortium, Inc released IMS RDCEO for describing, referencing, and exchanging definitions of competencies, primarily in the context of online and distributed learning. Mostly the specification information are unstructured text and intended for human interpretation. This specification provides means to create common understandings of competencies that appear as a part of a learning plan. The IMS RDCEO also provides a way to store competency information in many languages at a time.

IMS RDCEO specification contains following elements:

• Identifier : Globally unique label that identifies the Competency or Learning objects.

• Title : A single short mandatory human readable text for competency.

• Description : Human readable unstructured description of competency and this is an optional element.

• Definition : An optional structured description that provides more meaning to the competency.

• Metadata : An optional meta-data used to denote authors information, creation date etc. It is recommended that this should conform to IEEE LOM standard.

Definition element contains following sub elements :

• Model source : An identifier of the model or structure upon which the definition is based. It is good to have a URI as model source.

• Statement : Description about single characteristic of a definition and a definition must contain one or more statements.

• Statement Id : An optional string that is local identifier for the statement within the model

• Statement Name : This is an optional sub elements used to label the statement.

• Statement text : An optional unstructured textual description of those aspects of the competency referred to by the statement Name.

• Statement token : An optional vocabulary token, along with an identifier of the source of the vocabulary.

IMS LIP

IMS LIP describes the characteristics of a learner, which are needed for recording and managing learning-related history, goals, and accomplishments, engaging a learner in a learning experience, and discovering learning opportunities for learners. Here, the learner information is a collection of information about a learner (individual or group learners) or a producer of learning content (creators, providers or vendors). In competency modeling, the IMS LIP can be used to merge the competencies in IMS RDCEO and the users.

IMS LIP Core datastructures:

• Identification: Biographic and demographic data relevant to learning;
• Goal: Learning, career and other objectives and aspirations;
• Qualifications, Certifications and Licenses (qcl): Qualifications, certifications and licenses granted by recognized authorities;
• Activity: Any learning-related activity in any state of completion. Could be self-reported. Includes formal and informal education, training, work experience, and military or civic service;
• Transcript: A record that is used to provide an institutionally-based summary of academic achievement. The structure of this record can take many forms;
• Interest: Information describing hobbies and recreational activities;
• Competency: Skills, knowledge, and abilities acquired in the cognitive, affective, and/or psychomotor domains;
• Affiliation: Membership of professional organizations, etc. Membership of groups is covered by the IMS Enterprise specification;
• Accessibility: General accessibility to the learner information as defined through language capabilities, disabilities, eligibilities and learning preferences including cognitive preferences (e.g. issues of learning style), physical preferences (e.g. a preference for large print), and technological preferences (e.g. a preference for a particular computer platform);
• Securitykey: The set of passwords and security keys assigned to the learner for transactions with learner information systems and services;
• Relationship: The set of relationships between the core components. The core structures do not have within them identifiers that link to the core structures. Instead all of these relationships are captured in a single core structure thereby making the links simpler to identify and manage.

None of the above data structures is mandatory and also the multiple occurrences of these data structures are allowed. Each of these data structures itself has various sub elements.

An example :

An outcome is defined as "ability to identify verbs in simple sentences" and the scale is Aways, Sometimes and Never. If it is also defined that, learner can gets the "ability to identify verbs in simple sentences" competency if obtain Sometimes grade. Assume that a Lerner called Jenney has deemed this competency. This information can be modeled as follows using IMS RDCEO and IMS LIP. Here the Pseudo-Structures of IMS RDCEO and IMS LIP are used. Note that the given structure is not complete.

 IMS RDECEO Pseudo-Structure
rdceo.identifier = rdceo434323
rdceo.title = Identify verbs in simple sentences
rdceo.description = “Identify verbs in simple sentences”
rdceo.definition.statement.
   statementid = 123
   statementname = Always
   statementtext = Scale
   statementtoken = scl55435
rdceo.definition.statement.
   statementid = 124
   statementname = Never
   statementtext = Scale
   statementtoken = scl55436
rdceo.definition.statement.
   statementid = 125
   statementname = Sometimes
   statementtext = Scale
   statementtoken = scl55437

 IMS LIP Pseudo-Structure
lip.contenttype.referencial.sourceid.id = jenney_profile
lip.identification.cotenttype.referential.indexid = id123
lip.identification.name.partname.typename=Jenny 
lip.competency
   cotenttype.referential.indexid = j123
   exrefrecord = rdceo434323
   description = Always

Issues

1. Does completing a course mean all the outcomes in a course have been met? Or should we treat them independently of the course grade? Perhaps the admin needs to decide this as a setting.
2. How do we deal with the same outcome being used by more than one course? Should the admin specify an aggregation method for this?

See also

• GSOC/2008
• User Competency Tracking Module application abstract
• IMS RDCEO home
• IMS LIP home