Note:

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

Reporting improvements

From MoodleDocs

Introduction

Moodle captures an enormous amount of data about user activity. Information is accessible via various logs, course specific report and activity specific reports. The challenge for many administrators and others who need to review progress and performance data is that Moodle presents this data in a way that does not match well with the organisation’s or institution’s internal structures. In order to resolve this an interface is required that enables users with appropriate permissions to:

•Define reports

•Manage access to reports

What data does Moodle give use to report on?

Currently Moodle enables administrators (I’m using this term for anyone who needs to access progress and performance data) to access the following information:

System:

General activity logs – These can be filtered by single course, all users, single users, all dates or single date, all activities or single activity, various single actions e.g. view, update, display e.g. view on page, download (various)

Statistics

Various collections of general course level information (not enabled by default)

Course:

General activity logs – These can be filtered by single course, all users, single users, all dates or single date, all activities or single activity, various single actions e.g. view, update, display e.g. view on page, download (various)

Activity report: - Number of times an activity or resource has been accessed and date/time of last access.

Course participation report: Filter by single activity, period from now in days, single rle, “view” or “post” (grouped actions defined by activity type) Statistics - Various collections of general course level information (not enabled by default)

Completion tracking:

Course completion: Based on reaching all or a selection of user configurable completion criteria

Activity completion: See below

Gradebook:

Displays collated report for users with graded roles of: Course total grade, grade numerical grade or selected scale per activity (as defined in activity settings) and or selected Outcome(s) for the activity. Column averages. The grading method setting in Quiz and SCORM activities determines the value entered in the gradebook where multiple attempts are allowed.

Activity specific reports:

Quiz – Data for each attempt by learner. For each the following information is captured: Name, attempt state, started/completed, time taken, total grade, grade for each question (not shown in simple view). Filters for: users i.e. enrolled and attempted, enrolled not attempted etc. plus attempt status i.e. In progress, overdue, finished, never submitted. Column averages. (Full information on each question omitted from this summary).

For multiple attempts the value highlighted in the reports for each instance is the one matching the criterion selected in Grading method.

SCORM - Data for each attempt by learner. For each of the following information is captured: Name, number of attempts, whether attempted, started/completed, score, attempt (i.e. answer selected or entered). For each attempt: By SCO, status (completed, browsed, incomplete), time spent viewing the SCO, score (by completed SCO), “interactions by attempt. Also maximum and minimum score per SCO. The information available is dependant upon that in the SCORM package itself.

For multiple attempts the value highlighted in the reports for each instance is the one matching the criterions selected in Grading method.

Assignment: Data for each submission by learner (only one allow and submitted for grading status assumed here). Grade: Simple grading: Numeric or a single scale or the accumulated marks from the rubric or marking scale used. The previous options may also be supplemented by one or more Outcomes. Forum and Glossary: Have a ratings mechanism for a single numeric or scale rating to be applied to posts. The value transferred to the gradebook depends in the setting chosen for “Aggregate type”.

Workshop and Lesson omitted to save time at this stage.

Where enabled for the course, selected activities may have completion criteria applied. The completion status for activities contribution to course completion status is accumulated with course level completion criteria in the course completion table.

The potential activity completion criteria are illustrated in the following examples:

Assignment:

• Completion tracking: Not indicated, Student can mark as complete, When conditions are met.

• Require view (Student)

• Require grade (Student)

• Expected completion date

Quiz:

• Completion tracking: Not indicated, Student can mark as complete, When conditions are met.

• Require view (Student)

• Require grade (Student)

• Expected completion date

SCORM:

• Completion tracking: Not indicated, Student can mark as complete, When conditions are met.

• Require view (Student)

• Require grade (Student)

• Require minimum score

• Required status: Passed or Completed

• Expected completion date

Other activities and resources have completion criteria specific to their functionality.

Individual users:

Logs for general activity (today and since course start date) in the course in which accessed. Outline report of basic activity/resource information. Complete report with more detail of contributions.

Why isn’t the above entirely satisfactory?

To access the data above an administrator typically needs to visit a number of Moodle contexts and interfaces to retrieve data. This is especially true where the user is participating in more than one course.

In addition, reports on activity may be required on bases other than Moodle contexts. With the exception of Groups in courses users can only be reported upon in contexts to which they are assigned or lower contexts where permissions are inherited.

Augmented reporting capability

The following are my thoughts on how interfaces to improve the current situation could be evolved. There are 3 main interface areas:

• What is to be reported on i.e. courses, activities, attempts, actions

• Who is to be reported on

• Who can view and manage reports


What is to be reported on

Report configuration screens should progressively narrow down the data required in the report.

Screen 1: Display all courses in category tree. Select courses on which report should be based.

Screen 2: Display selected courses with activities listed. By default only activities with grading mechanism should be listed. Select activities to be included in the report.

alt text

Screen 3: For each course/activity remaining, “quick report” checkboxes for commonly required report items e.g. information sent to gradebook, completion status (if enabled).

Further link to detail page where more specific report criteria can be defined.

Screen 4: Detail page for course or activity.

alt text

System example detail options for report:

• Never logged in

• First login

• Last login

Course example detail options for report:

• First access

• Last access

• Course complete

• Course grade

• Group name(s) where user is a member

• Course role

• Enrolment method (where Cohort include cohort name)

Quiz example detail options for report:

• Attempted

• Date /time of first attempt completed

• Total number of attempts

• Highest grade

• Attempt when highest grade achieved

• Date / time for attempt when highest grade achieved

• Grading method grade

• Grades for attempts i.e. grades for attempts 1, 2 and 3

• Date/time of first attempt

• Activity complete

Assignment example detail options for report:

• Submitted status i.e. submitted, draft, no submission

• Due date status i.e. lateness

• Graded status

• Date / time submitted

• Date / time graded

• Grade

• Outcomes

• Activity complete

SCORM example detail options for report:

• Attempted

• Date /time of first attempt completed

• Total number of attempts

• Highest grade

• Attempt when highest grade achieved

• Date / time for attempt when highest grade achieved

• Grading method grade

• Grades for attempts i.e. grades for attempts 1, 2 and 3

• Date/time of first attempt

• Status for (all) SCOs i.e. completed, Browsed, incomplete

• Activity complete

General:

Need options to add new, delete, copy and edit reports.

Who is to be reported on

Screens to progressively filter users:

Screen 1:

Select report i.e. What is to be reported on.

Typical defaults e.g. report on graded roles from Site admin gradebook settings.

Option to select roles to be reported upon by course

Active users (default)

Suspended users

Screen 2:

alt text

Group(s) to be included in report by course.

Option for all users

Option to include users not in a group.

Must be possible to report on more than one group per course i.e. multi-select or ability to add further single select drop-downs.

Screen 3:

Filter on standard profile user fields and bespoke user profile fields

Without specific development of functionality to associate users with an external hierarchy User profile fields are the only way I can think of to reflect this.

Who can view and manage reports

I think this will require a view and manage reports capability.

View:

Screen 1: Default option of users with view reports permissions in all of the courses included in the report because they are:

• Assigned to a permitted role; or

• Assigned to a permitted role in “Other roles”; or

• Inherit the required permissions from a higher context

Screen 2: Specific users (from pick list)

Screen 3: Users filtered on role and User profile fields

Manage:

Similar to the above?

Report format:

General considerations:

HTML table and CSV export (fancy charts can follow later)

In addition to info above option to include items ticked in User policies > Show user identity

Sortable by header

Ability to minimise column width