Note:

If you want to create a new page for developers, you should create it on the Moodle Developer Resource site.

Progress tracking

From MoodleDocs

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

An outcome is a statement with a scale.

eg "Can identify verbs in simple sentences" - Never, Sometimes, Always

A competency is a skill gained when person is deemed to have successfully achieved an outcome.

eg Jenny can identify verbs in simple sentences  "Always"


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 this area to be able to import and export this sort of information.


IMS RDCEO

IMS Global Learning Consortium, Inc released a specification called IMS Reusable Definition of Competency or Educational Objectives (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 learning plan. The IMS RDCEO 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 Learner Information Package 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, discovering learning opportunities for learners. Here 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 the competency modeling, the IMS LIP can be used to merge the Competencies in IMS RDCEO and the users.

IMS LIP Core data structures:

  • 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 above data structure is mandatory and multiple occurrences of these data structures are also allowed. Each of this data structure itself has various sub elements.


IMS RDCEO - LIP : An example


 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

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