MoodleDocs - User contributions [en]

Reporting improvements

2012-09-04T21:16:18Z

Ray: /* What is to be reported on */

==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 "module", status (completed, browsed, incomplete), time spent viewing the "module", score (by completed "module"), “interactions by attempt. Also maximum and minimum score per "module". 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.

[[File:rep1.jpg|200px|thumb|right|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.

[[File:rep2.jpg|200px|thumb|right|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:'''

[[File:rep3.jpg|200px|thumb|right|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

Reporting improvements

2012-09-04T21:15:54Z

Ray: /* What is to be reported on */

Reporting improvements

2012-09-04T21:15:41Z

Ray: /* What is to be reported on */

Reporting improvements

2012-09-04T21:15:10Z

Ray: /* What is to be reported on */

Reporting improvements

2012-09-04T21:14:30Z

Ray: /* Activity specific reports: */

Reporting improvements

2012-09-04T21:13:53Z

Ray: /* Activity specific reports: */

==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 "module", status (completed, browsed, incomplete), time spent viewing the "module", score (by completed "module"), “interactions by attempt. Also maximum and minimum score per "module". 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.

[[File:rep1.jpg|200px|thumb|right|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.

[[File:rep2.jpg|200px|thumb|right|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:'''

[[File:rep3.jpg|200px|thumb|right|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

File:rep3.jpg

2012-09-04T21:12:33Z

Ray:

Reporting improvements

2012-09-04T21:12:13Z

Ray: /* Who is to be reported on */

==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.

[[File:rep1.jpg|200px|thumb|right|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.

[[File:rep2.jpg|200px|thumb|right|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:'''

[[File:rep3.jpg|200px|thumb|right|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

Reporting improvements

2012-09-04T21:11:30Z

Ray: /* What is to be reported on */

==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.

[[File:rep1.jpg|200px|thumb|right|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.

[[File:rep2.jpg|200px|thumb|right|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:'''

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

File:rep2.jpg

2012-09-04T21:10:24Z

Ray:

File:rep1.jpg

2012-09-04T21:09:50Z

Ray:

Reporting improvements

2012-09-04T21:09:19Z

Ray: /* What is to be reported on */

==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.

[[File:rep1.jpg|200px|thumb|left|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.

[[File:rep2.jpg|200px|thumb|left|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:'''

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

File:Example.jpg

2012-09-04T21:03:52Z

Ray: uploaded a new version of "File:Example.jpg": Reverted to version as of 09:17, 3 June 2011

Reporting improvements

2012-09-04T21:03:25Z

Ray: /* What is to be reported on */

==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.

[[File:Example.jpg]]
'''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.

[[File:Example.jpg]]

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:'''

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

File:Example.jpg

2012-09-04T21:01:59Z

Ray: uploaded a new version of "File:Example.jpg": Reverted to version as of 21:00, 4 September 2012

File:Example.jpg

2012-09-04T21:01:24Z

Ray: uploaded a new version of "File:Example.jpg": Reverted to version as of 09:17, 3 June 2011

File:Example.jpg

2012-09-04T21:00:43Z

Ray: uploaded a new version of "File:Example.jpg"

Reporting improvements

2012-09-04T20:57:02Z

Ray: /* General: */

==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.

'''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.

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:'''

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

Reporting improvements

2012-09-04T20:55:48Z

Ray: /* Who can view and manage reports */

==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.

'''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.

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:'''

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

Reporting improvements

2012-09-04T20:55:32Z

Ray: /* Who is to be reported on */

==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.

'''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.

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:'''

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

Reporting improvements

2012-09-04T20:55:08Z

Ray: /* Who is to be reported on */

==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.

'''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.

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:'''

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

Reporting improvements

2012-09-04T20:53:44Z

Ray: /* General: */

==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.

'''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.

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:'''

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

Reporting improvements

2012-09-04T20:52:42Z

Ray: /* General: */

==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.

'''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.

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:'''

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

Reporting improvements

2012-09-04T20:51:16Z

Ray: /* What is to be reported on */

==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.

'''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.

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:

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

Reporting improvements

2012-09-04T20:48:22Z

Ray: /* What data does Moodle give use to report on? */

==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.

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.

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:

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

Reporting improvements

2012-09-04T20:45:07Z

Ray: /* Introduction */

==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 illustrate din 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.

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.

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:

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

Reporting improvements

2012-09-04T20:44:16Z

Ray: Created page with "==Introduction== Moodle captures an enormous amount of data about user activity. Information is accessible via various logs, course specific report and activity specific reports..."

==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 origination’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 illustrate din 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.

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.

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:

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

Media embedding

2012-07-15T19:20:14Z

Ray: /* Flash and security */

[[Category:Interfaces]]
{{Moodle 2.3}}
{{Work in progress}}

From Moodle 2.3, a new API can be used to embed media items. Media items are:

* Audio files.
* Video files.
* Flash files.
* Audio, video, or similar content embedded from remote websites (currently YouTube and Vimeo).

== Automatic embedding ==

As in previous versions of Moodle, you do not need to do anything special to embed media files in text that users enter. This text is processed by the mediaplugin filter, which (if enabled) will automatically embed media files when users enter a link to the media.

You only need to use the API on this page if you want to embed media files as part of output generated by your plugin, rather than generated by user text.

== Embedding media ==

To embed a media file, use the following code:

<code php>
$mediarenderer = $PAGE->get_renderer('core', 'media');
echo $mediarenderer->embed_url(new moodle_url('http://example.org/a.mp3'));
</code>

=== Size ===

You can supply video size in two ways:

* As parameters to the embed_url function.
* At the end of the URL as #d=640x480 (d is short for 'dimensions')

A #d in the URL will override the function parameters.

If you don't supply size, you get default behaviour. Note that some players are capable of automatically determining the correct size, so it is better not to supply size unless you're sure of it.

Question: how will default behaviour be determined? From the video information or some presets in Moodle?

=== Name ===

You can also supply an optional name as a parameter to the embed_url function. The system uses this in various places where a title for the content is required. If you don't supply a name, the filename is used.

If the user does not have any plugins installed that are capable of playing your video, they will see a link containing this text.

=== Multiple formats ===

To get the most compatible results, you can supply more than one file in order to provide the same media content in multiple formats. The system automatically sets up appropriate fallbacks so that your file is likely to play.

Note: The best results are obtained if you supply a file that Flash can play (.f4v or .flv), and also an MPEG-4 file which is formatted for mobile devices (.mp4 or .m4v). This combination should play on all common devices and browsers.

<code php>
$mediarenderer = $PAGE->get_renderer('core', 'media');
$files = array(new moodle_url('http://example.org/a.m4v'), new moodle_url('http://example.org/a.f4v'));
echo $mediarenderer->embed_alternatives($files);
</code>

In the media filter, we let users automatically generate these effects using a URL like this:

http://example.org/a.m4v#http://example.org/a.f4v#d=400x300

If you want to support this kind of multi-URL string in your own code, use the core_media::split_alternatives function.

=== Flash and security ===

Allowing ordinary users to embed Flash on your website, which other users can then view, creates a serious security risk. By default, the embed code shown above will not embed Flash .swf files; these will be included as a download link instead.

If the media content that you are embedding can only be set up by trusted users such as teachers, then you should use the core_media::OPTION_TRUSTED option when you embed content. This will allow Flash content to be embedded.

<code php>
$mediarenderer = $PAGE->get_renderer('core', 'media');
$options = array(core_media::OPTION_TRUSTED => true);
echo $mediarenderer->embed_url(new moodle_url('http://example.org/a.mp3'), '', 0, 0, $options);
</code>

"Trusted users" are Managers and Teachers by default. site:trustcontent capability is required. See https://docs.moodle.org/23/en/Site_policies#Enable_trusted_content

=== Other options ===

Two other options are currently available at time of writing.

* core_media::OPTION_NO_LINK: Disables the download link fallback. Users who don't have a suitable player plugin will see nothing at all. This option should be used if you always print a visible download link separately, as there is then no need for a fallback link.

* core_media::OPTION_EMBED_OR_BLANK: Depending on the filetype and server options it might not be possible to embed the file. Normally the system outputs a download link in that case. Using this option causes it to return an empty string. Use the option if you're going to check the return value and do something different if it isn't possible to embed the file. (Note: This option is based on server settings, not on the current user. If the system is able to create embed code for the file, then this code will be returned and not blank, even if the current user doesn't have the right plugin installed.) You can also achieve the same effect by separately calling the $mediarenderer->can_embed_url() function.

== Changing media embedding behaviour ==

If you want to change the media embedding behaviour in all locations within your own Moodle installation, you can do that by overriding the core_media_renderer class.

You can [[Themes_2.0_overriding_a_renderer|override renderers within a theme]].

=== Changing player list ===

In your renderer which extends core_media_renderer, you will typically want to override the get_players_raw function to either add new player classes to the array, remove existing ones, or both. For example, if you create a different way to embed FLV files, you could remove the existing flv renderer and add a new one using the following function:

<code php>
protected function get_players_raw() {
$original = parent::get_players_raw();
unset($original['flv']);
$original['flv'] = new theme_mytheme_myflvplayer();
return $original;
}
</code>

=== Writing a new player ===

Writing player classes is easy. Your player class should extend core_media_player if it handles a file type (like FLV), or core_media_player_external if it handles URLs for an external site (like YouTube).

Here is an example player class for a new video format called .frogvideo:

<code php>
class core_media_player_frogvideo extends core_media_player {
public function embed($urls, $name, $width, $height, $options) {
// $urls is a list of the alternative urls supported by this player
// (i.e. that end in .frogvideo) - you use this list to construct
// the embed html.

// Just return the html code to embed this player. Some part of the
// html should include code that appears if the user doesn't have
// a suitable plugin installed; put the placeholder at that point.
return '...HTML code...' . core_media_player::PLACEHOLDER . '...';
}

public function get_supported_extensions() {
return array('frogvideo');
}

public function get_rank() {
// If you want this player to be used in preference to the existing
// ones, use a bigger rank number than existing players.
return 111;
}
}
</code>

For more detail about the available functions and more complex use cases, look at the PHP documentation for core_media_player in medialib.php.

== Current documentation ==

To see current in-code documentation, look in the files lib/medialib.php and at the class core_media_renderer in lib/outputrenderers.php.

Talk:Paged course formats

2012-04-13T14:21:02Z

Ray: /* Some thoughts */

==Introduction==
What is the general idea of 'Paged course formats'? - Will it be that you get to see the section name as a list, then if you wish to view it opens in a new tab within the browser?

==Discussions around this==
http://moodle.org/mod/forum/discuss.php?d=175758#p770737

==Some of the options currently around for alternative formats==
Representing several different approaches.
#http://server3.moodle.com/browse/MDL-28555

===FOLDERVIEW===
Doed much more than just offer page view. Eiting magic as well.
#Folderview Blog post: http://thinkingdistance.org/post/6486856003/folderview-course-format
#Comments by Michael: http://server3.moodle.com/browse/MDL-27646 Including Folderview in Moodle 2

Paul's comment: "Paul Chapin added a comment - 07/Jun/11 3:20 AM : The folder view format doesn't really do it. Basically, that's just a topic format with a different interface. It doesn't deal with the situation of the instructor who wants to make a large amount of reference information, usually files and web links, available as part of a topic or week without visually overwhelming the students. By allowing for a hierarchical structuring of material using folders the amount of information the student is presented with at any given time can be limited and organized logically. It's really files and links that we want, but if that's implemented, adding the rest of the resource types should be fairly straight forward" MDL-27646

===FLEXPAGE===
Unsure of status for 2.
#Flexipage and Moodle 2.0: http://moodle.org/mod/forum/discuss.php?d=83817#p74318

===COLLAPSED===
Three forms: Topics, Weeks and Latest First
#http://moodle.org/plugins/view.php?plugin=format_topcoll - Same as Topic's format but with a 'toggle' and a cookie to remember state per user per course that can be persistent. Developed much further - see CONTRIB-3378 below.
#http://moodle.org/plugins/view.php?plugin=format_weekcoll - Same as Week's format but with a 'toggle' as above.
#https://github.com/gjb2048/moodle-format_latfirst - Same as above but current week is displayed first and preceding weeks after for the user. In 'editing' mode it is the same as Collapsed Weeks.

Combined into one:
#CONTRIB-3378
Which has four forms: Topics, Weeks, Latest Week First and Current Topic First. Available from [http://moodle.org/plugins/view.php?plugin=format_topcoll Modules & Plugin's Database] and documented on [https://docs.moodle.org/22/en/Collapsed_Topics_course_format Collapsed Topics Course Format]

Above collapsed forms developed by [http://moodle.org/user/profile.php?id=442195 Gareth J Barnard].

===BLOCK===
Experimental jQuery Masonry (#http://masonry.desandro.com/) format for Moodle 2.1:
#https://github.com/gjb2048/moodle-format_topmas - Uses the jQuery Masonry plugin to arrange sections as close together as possible. Resizes automatically depending on content.

===GRID===
Not strictly a "paged format" But getting very good reviews. Looks classy.
#http://moodle.org/plugins/view.php?plugin=format_grid Seems a good option

"The Grid Format was originally contributed by Paul Krix. It has since been updated and is now maintained ny Pukunui Technology. This format adds a more graphical interface to viewing Moodle topics and also avoids the "scroll of death" issue by using placeholder graphics to represent each topic. When clicked upon, these graphics launch the topics in ajax windows" from https://github.com/moodleman/moodle-courseformat_grid

===COURSE MENU===
There are at least two in plugins:
#
#
Plus Lei Zhang (and Awesome Moodle) bar

Catalyst have coded two options included in Moodle in Schools package.

==Section Menu Option==

==OU format option==

== Some thoughts ==

1. For weekly courses, one page per section is not necessarily ideal. Instead the OU course format (studyplanner) by default just shows the current week (highlighted) with +- n weeks either side. There is then a link 'Show entire study planner' if you need to find something else. Section 0 is always visible. I think this is a good model (speaking as an OU student here). However, the 'mdl_course.coursedisplay' proposal, with just two settings, does nothing to make this easier. Therefore, I am skeptical about the value of hard-coding that into Moodle core.--[[User:Tim Hunt|Tim Hunt]] 20:09, 12 April 2012 (WST)

Yes, agreed. But how many extra settings can users cope with before they give up? A good case for admin defined course defaults and "Advanced" settings. [[User:Ray Lawrence|Ray Lawrence]]

I wonder whether it would be better to use the course format settings rather than adding a field to the course table for this. This would enable each course format to define it's own settings but would mean a change in priorities for the workload --[[User:Andrew Nicols|Andrew Nicols]] 21:59, 13 April 2012 (WST)

2. Even if you press on with your plan, it seems silly to just list the weeks on the course front page in weekly format. Surely it is worth displaying the current week in full there. It will save students one click almost every time they visit the course.--[[User:Tim Hunt|Tim Hunt]] 20:09, 12 April 2012 (WST)

Agree. [[User:Ray Lawrence|Ray Lawrence]]

Actually, Tim, this is more or less what I was referring to with the "Accordion" format as a third option in that menu. Basically it's Gareth's [[Collapsed_Topics_course_format|Collapsed Format]]. It would look as you describe and the other sections would be clickable and would expand in-place. I can see it's probably it's less clicks for the weekly and topics format to expand the currently-selected section on the main course page even in the one-section-per-page format, but I'm a little worried about the inconsistency of the interface. Happy to do it if there's no other objections though. [[User:Martin Dougiamas|Martin Dougiamas]] 15:58, 13 April 2012 (WST)

It's quite hard to work out what is being proposed. Is it one section/week on a page or a collapsible format. both. A sketch would be handy. [[User:Ray Lawrence|Ray Lawrence]]

3. Has anyone at HQ actually downloaded and installed the OU's subpage module? I know it solves a separate problem, but please spend some time looking at it now for two reasons. A. When you do the "Check for regressions in modules caused by course assumptions" bit, you should try to ensure that they benefit modules like subpage, as well as your course format changes. B. Subpage functionality might be worth adding to Moodle too, and the code already exists and works.--[[User:Tim Hunt|Tim Hunt]] 20:09, 12 April 2012 (WST)

My reservation about this is that it adds a layer the location of which isn't clear to users. I don't think we can have a format that add an element of mystery to the masses. Think how confused uders can be by activities in Orphaned courses if one isn't careful with it. [[User:Ray Lawrence|Ray Lawrence]]

I've looked at it. Sorry it's just too much to add on at this stage with the short time period and so much to do already. [[User:Martin Dougiamas|Martin Dougiamas]] 15:58, 13 April 2012 (WST)

4. Be very careful when defining format_renderer_base. If you have format_weekly_renderer extends format_renderer_base, and format_renderer_base generates output for something, then a theme cannot do theme_mytheme_format_renderer cannot usefully extend format_renderer_base to change the output, because format_weekly_renderer still extends format_renderer_base, and not theme_mytheme_format_renderer. (I made this mistake in a few small ways with question_type_renderer base, e.g. the feedback_image mehthod, although I mostly got it right by creating core_question_renderer to output the common parts of questions.) Basically, prefer composition over inheritance (http://c2.com/cgi/wiki?CompositionInsteadOfInheritance).--[[User:Tim Hunt|Tim Hunt]] 20:09, 12 April 2012 (WST)

5. I am worried that you are trying to do this in a rush before the 2.3 deadline, particularly if you are not going to delay mdl_course.coursedisplay until 2.4. It occurs to me that a lot of this could be done initially in third-party course-format plugins. Then, once everyone can see it working, and has been bowled over by how amazing it is (assuming you are right, and I am wrong) you can then refactor the code into Moodle core.--[[User:Tim Hunt|Tim Hunt]] 20:09, 12 April 2012 (WST)

Frankly these exist already and do it in all kinds of wierd ways. I want a simple setting that implements it in core formats in the simplest possible way. Others are free to build on top of it with plugins later. [[User:Martin Dougiamas|Martin Dougiamas]] 15:58, 13 April 2012 (WST)

5.1 I disagree with Tim over implementing initially in third-party course-format plugins. As this is a 'core' functionality change it should be implemented there as 'gospel' way of implementing the functionality so that there is no confusion over interpretation of how it should work. Because if each contrib developer takes their 'view' then we will have a mismash that will have to be sorted and then the contrib developers have to refactor back to the HQ defined standard. I don't live and breathe PHP or Moodle (sacrilege I know) so tend to follow and adapt the 'guru' written code in the core formats as a basis of learning and implementing the correct functionality, hence I consider a core 'guru gospel' implementation to be the better solution. [[User:Gareth Barnard|Gareth Barnard]] 21:20, 12 April 2012 (WST)

Agree. It's fundamental stuff. Let's take it steady. In core.[[User:Ray Lawrence|Ray Lawrence]]

5.2 I do agree with the thought of it being rushed as although I consider a lot of users have been screaming for this for ages, it would be better to get it right first time even if this takes a little longer. As a bodge job could put users off Moodle completely and cause them to lose faith in the quality of the product. [[User:Gareth Barnard|Gareth Barnard]] 21:20, 12 April 2012 (WST)

6. We have not yet published the Moodle 2.x code for the studyplanner course format, but if anyone want to see it, we can probably share it. Just ask.--[[User:Tim Hunt|Tim Hunt]] 20:11, 12 April 2012 (WST)

7. Do we really want the course format options to be part of the already very long and complex course settings form. Whey not have a separate link in the settings block for 'Weekly format options', or something like that. Much simpler all round.--[[User:Tim Hunt|Tim Hunt]] 20:13, 12 April 2012 (WST)

Yeah simpler but will they see it there? Some of the settings are quite key ... [[User:Martin Dougiamas|Martin Dougiamas]] 15:58, 13 April 2012 (WST)

8. I override the function 'section_class.prototype.swap_with_section' in '/lib/ajax/section_classes.js' in the contributed 'Collapsed Topics' course format because I use a table for my layout and hence two table rows per section. Therefore, will I still be able to do this? Before I get blamed for using a 'table' tag instead of a 'div' tag and a set of 'ul' tags, tables work for me because the layout is tabular and conceptually is a table in the Object Orientated sense (bar the three/four/more legs), and indeed the W3C specification of a '[http://www.w3.org/TR/html4/struct/tables.html table]' states 'The HTML table model allows authors to arrange data -- text, preformatted text, images, links, forms, form fields, other tables, etc. -- into rows and columns of cells.' and that is exactly what I am doing as an arrangement of the sections as rows and columnar subdivision of content / section information. It also works better with Internet Explorer and manipulating the Document Object Model with JavaScript at the client end. [[User:Gareth Barnard|Gareth Barnard]] 21:20, 12 April 2012 (WST)

Eagerly awaiting this, a few comments on the spec.

-The section name (as a link to the separate page)

I'm having visualising this, could you add a mock up to clarify intentions.

- Controls to hide/show that section, as usual

Is this referring to Hidden sections?

- Tthe section summary (truncated if it’s too long)

IMO any automatic setting here will cause issues. Course designer needs to be able to add content as required. It's up to them to manage.

- More sections can be added by a big "plus" icon at the bottom, and old ones can be deleted if they are empty.

In both paged and standard layouts? Would be great.

- The section pages should be seen as "sub" pages of the course page and can have their own blocks.

This could make things pretty complicated.

What would happen if teacher switched to standard view from paged?

How would Nav and settings block behaveon a page?

- There is no longer need in per-user setting to show only one section in the course (it confused people anyway).

So what happens with legacy courses where this in use and standard layout courses when users want to focus on a single section/week?

- Add a user preference controlled by link/button in UI to switch between old-style menu (for expert users) and this new-style pop up (as default, for new users).

Expert users? My vote is for one method

- Extend course settings with format support

Ideally this would be extended to set defaults in the adminitration course defaults. This would be popular and more user friendly than the current change config.php approach.

[[User:Ray Lawrence|Ray Lawrence]]

Talk:Cohorts

2010-03-31T09:53:35Z

Ray:

The goals specified seem to cover exactly what I think the use case for 'global groups' are :) --[[User:Dan Poltawski|Dan Poltawski]] 23:50, 8 March 2010 (UTC)

It would be useful to expand the comments about replacing category enrolments. Assignment to a role for a category e.g. as course Creator is a method used extensively to provide delegated permissions by department, school etc. It would be a shame for this to be lost in 2.0.

Will cohorts be role agnostic in the same way as course groups?

The following is a frequently asked for use case that doesn't seem to be catered for in specification here:

Site administrator (or others with relevant permissions) can allocate to a cohort e.g. cohort a, cohort b.

The site administrator wants to hand over responsibility for allocating users to cohort a to a user in cohort a who has the necessary permissions. This user should not be able to access any other cohort or allocate users to them. Are the new capabilities granualar enough to facilitate this? --[[User:Ray Lawrence|Ray Lawrence]] 09:53, 31 March 2010 (UTC)

Talk:Resource module file API migration

2009-06-15T13:28:25Z

Ray:

==Current problems==
embedded images are lost during backup & restore which moves the course to a new site. -- Matt Gibson 08:53, 18 May 2009 (UTC)

==Separate contrib modules==
New local files module - contrib - ???? --Eloy Lafuente (stronk7) 16:21, 19 May 2009 (UTC)
mod/resource/type/file/localfile.php is a win32 only hack which is not maintained much these days Petr Škoda (škoďák)

==Extracted from HQ chat, pending to confirm (Y/N)==
I liked the :

* 0 = native 2.0
* 1= flagged as migrated
* 2= pending to migrate
* lastmodified = for still being migrated-on-demand resources

- so, anything with flag > 2 is susceptible to be marked as migrated (1) by any process (manual/automatic or whatever we can implement) and, at the same time, we keep native (0) and flagge (1) d separate, helping to know the orgin of the resource in case we need it later.

- so, on upgrade... I'd mark everything as pending to migrate (2) and then, think on possible ways to perform the lastmodified => 1 conversion (but never to 0. it's reserved for native 2.0)

--[[User:Eloy Lafuente (stronk7)|Eloy Lafuente (stronk7)]] 09:38, 28 May 2009 (UTC)

==TODO - explain exactly how pluginfile can derive ...==
Here it's a tentative explanation:

The whole path (within legacy course files) will be fully retained when copying files to the resource files area.

So for example, if we have one resource pointing to: ''"some/dir/with/index.html file"'', the ''"some/dir/with"'' directories will be created (if don't exist) in destination resource file area and then the ''"index.hml"'' file will be copied there (also, if don't exist, obviously).

Then, advancing in the example, if that html includes one link to say: ''"another/different/dir/style.css"'', then the ''"another/different/dir"'' dir will be created (once again, if it doesn't exist) and then the ''"style.css"'' file with be copied there (do you guess when? :-P ).

That way, by retaining the "relative paths" present in legacy course files when copying them to 2.0 resource file areas, the only change will be that old resources being server by "file.php" will be now served by "pluginfile.php", (with different parameters related to course/context/filearea, not important) but 100% equivalent in all their relative links.

--[[User:Eloy Lafuente (stronk7)|Eloy Lafuente (stronk7)]] 09:49, 28 May 2009 (UTC)

== Some comments from Tim ==

Brilliant! Excellent detailed spec. Just a few comments:

I added a few comments inline in the main page becuase it seemed easier. Please see main page history.

For the resource_historic table - in the blocks code I used block_instance_old. old is shorter, is it worth being consistent?

mod/page -> Show course blocks options. Martin said that that option could just be removed.

is mod/link a better name than mod/url?

mod/imspackage I have normally seen IMS Content Packaging abbreviated as IMS-CP. Since IMS may come out with other packaging schemes in the future, might it be better to call the module mod/imscp? Or would it be better to have one module to support all the packaging formats that we support? That is, should we go the other way and call it mod/contentpackage? (No, becuase SCORM will still be separate, and anyway, that name is too long.)

--[[User:Tim Hunt|Tim Hunt]] 05:34, 9 June 2009 (UTC)

== Some comments from Ray ==

* References to "Directory". This is terminology that most teachers, trainers etc. are not familiar with. A good time to standardise on the term "folder". MDL-11841

* Perhaps update spec table from "Links to external files in repositories (ie Hive)" to "Links to external files in repositories (e.g. Hive) ".

-- Ray Lawrence 15/6/09

Navigation 2.0

2009-02-07T15:05:56Z

Ray: /* Relevant tracker issues */

{{Moodle 2.0}}
==Goals==

Improving navigation in a complex web application like Moodle touches on a lot of areas, but in particular we must aim to hit these goals:

===Clarity===

It should be clearer what settings affect only yourself, and what settings affect what others see.

It should be clear what is global navigation (whole site), and what is local navigation (within a course or module).

===Consistency===

All parts of the interface should be consistent. We need to have a set of guidelines and core frameworks to better restrict what developers are allowed to do, while also reworking the core code to implement things like blocks and tabs in consistent ways.

===Usability===

Users should be able to easily learn what is there for them.

Users should be able to move around "their world" within Moodle with a minimum of effort.

===Performance===

Processing blocks and building up a page with navigation must be very efficient.

===Backward compatibility===

If possible, plugins should not have to change.

Users should also not find the new interface too different (just better!)

==Scope==

What parts of Moodle might be affected by this work?

===Navigation bar===

Since Moodle 1.9, we construct the navigation bar from an array using the build_navigation function. However, that converts all the data to a string, which is then passed to the theme. Instead, we should keep the information about the navigation bar links as structured data, and let the theme choose how to render it.

===Local navigation===

In different places we have the global administration tree, the Course admin block, the Jump to menu, tabs like in the user profile, various activities, in the roles UI, and the 'Update this forum' button. These are all ways of getting around nearby, related pages. It would be good to make these concepts more consistent. (There is also $homelink in the footer. Currently the HTML for this is generated in print_header.)

'''This is an area we need to think about a lot more'''
:Please discuss here: http://moodle.org/mod/forum/discuss.php?d=115620

===Blocks/pagelib===

Blocks themselves should not change. What is currently inconsistent is how blocks get associated with particular pages. At the moment this is done through the (pageid, pagetype) columns of block_instance, and the pagetype column of block_pinned. Does it work if we change this to (contextid, pagetype)?

The other thought is, can we make sticky blocks more flexible? What if we let them be configured in any context, not just globally? This would let people do things like add a block to every course in a particular category.

Perhaps let themes control where on the page blocks can appear.

'''Some more thought required here'''.
:Please discuss here: http://moodle.org/mod/forum/discuss.php?d=95882

===Course view===

What do we need on top of the existing course formats?

===Themability===

Give themers as much flexibility as possible, without having to do major changes throughout Moodle.

Let them change the HTML output by the print_XXX functions in weblib.php.

Should we allow themes to have their own lang files and settings.php page in the admin tree?

==Design==

As I write this, we don't have a clear overview of the whole solution, but following some discussions, I have some ideas about how some components of the solution should work, and I want to write them down. Therefore, I present [[Navigation/Pagelib/Blocks 2.0 design|a possible (partial) design]]. (Real development never happens as they teach in Software Engineering classes anyway. ;-) )--[[User:Tim Hunt|Tim Hunt]] 23:28, 29 January 2009 (CST)

==Relevant tracker issues==

These come from a review of all the [http://tracker.moodle.org/secure/IssueNavigator.jspa?reset=true&pid=10011&resolution=-1&component=10088&sorter/field=issuekey&sorter/order=ASC&sorter/field=priority&sorter/order=DESC 'Theme' tracker issues].

* MDL-3625 $menu in header does too many things
* MDL-3626 header.html and footer.html $variable inconsistency
* MDL-8369 Folder-like presentation of the courses at the main page
* MDL-9306 Main course formats need to have tables removed but keep AJAX working - ''there seem to be some regressions from this work ;-)''
** MDL-12164 Hiding Course Topics and Switching Roles creates Problem in other Topics
** MDL-13410 Course view misaligned
** MDL-17450 Display of blocks and topic section not correct in 2.0
* MDL-10522 Hard-coded <br /> used for spacing.
** MDL-14058 Code includes <br /> tags in many places, which breaks theming, or makes it more difficult
* MDL-10681 Popup windows need uniform body class
* MDL-12093 It is not possible to change the page layout in popup windows
* MDL-12183 Improve block HTML structure
* MDL-12191 Let themes know whether this page has blocks.
* MDL-14061 Add category short names, and an option for categories in the navigation bar.
* MDL-14305 Class on body to identify the page as Moodle, and a specific site. (Enables sharing of stylesheets, but with a few specific customisations.)
* MDL-14306 The course category hierarchy should be reflected in CSS classes on the body tag (actually, contextids would let this be done more efficiently).
* MDL-14539 Replace table layout with div - ''parhaps a duplicate of MDL-9306.''
* MDL-14632 Increase use of tabs on all mod activities.
* MDL-14901 Themes can no longer control the separater used in the nav bar.
* MDL-15400 Sideblocks on "My Moodle" page not conforming to global width
* MDL-15817 Part course them and part site theme is used when displayng Outline and Complete reports
* MDL-15959 patch any theme to have a personal visual style (CSS file) for each course - ''not sure this is a good solution, but it is an interesting requirement.''
* MDL-16244 Support for a drop-down menu bar - ''Like on moodle.org now''.

==See also==

* [[Roadmap]]
* [http://moodle.org/mod/forum/discuss.php?d=108993 General developer forum discussion about templates]
* [http://moodle.org/mod/forum/discuss.php?d=95882 General developer forum discussion about blocks/pagelib]
* [http://moodle.org/mod/forum/discuss.php?d=115389 Forum discussion about having blocks on the category pages]

Navigation 2.0

2009-02-07T15:03:23Z

Ray: breadcrumbs --> navigation bar

{{Moodle 2.0}}
==Goals==

Improving navigation in a complex web application like Moodle touches on a lot of areas, but in particular we must aim to hit these goals:

===Clarity===

It should be clearer what settings affect only yourself, and what settings affect what others see.

It should be clear what is global navigation (whole site), and what is local navigation (within a course or module).

===Consistency===

All parts of the interface should be consistent. We need to have a set of guidelines and core frameworks to better restrict what developers are allowed to do, while also reworking the core code to implement things like blocks and tabs in consistent ways.

===Usability===

Users should be able to easily learn what is there for them.

Users should be able to move around "their world" within Moodle with a minimum of effort.

===Performance===

Processing blocks and building up a page with navigation must be very efficient.

===Backward compatibility===

If possible, plugins should not have to change.

Users should also not find the new interface too different (just better!)

==Scope==

What parts of Moodle might be affected by this work?

===Navigation bar===

Since Moodle 1.9, we construct the navigation bar from an array using the build_navigation function. However, that converts all the data to a string, which is then passed to the theme. Instead, we should keep the information about the navigation bar links as structured data, and let the theme choose how to render it.

===Local navigation===

In different places we have the global administration tree, the Course admin block, the Jump to menu, tabs like in the user profile, various activities, in the roles UI, and the 'Update this forum' button. These are all ways of getting around nearby, related pages. It would be good to make these concepts more consistent. (There is also $homelink in the footer. Currently the HTML for this is generated in print_header.)

'''This is an area we need to think about a lot more'''
:Please discuss here: http://moodle.org/mod/forum/discuss.php?d=115620

===Blocks/pagelib===

Blocks themselves should not change. What is currently inconsistent is how blocks get associated with particular pages. At the moment this is done through the (pageid, pagetype) columns of block_instance, and the pagetype column of block_pinned. Does it work if we change this to (contextid, pagetype)?

The other thought is, can we make sticky blocks more flexible? What if we let them be configured in any context, not just globally? This would let people do things like add a block to every course in a particular category.

Perhaps let themes control where on the page blocks can appear.

'''Some more thought required here'''.
:Please discuss here: http://moodle.org/mod/forum/discuss.php?d=95882

===Course view===

What do we need on top of the existing course formats?

===Themability===

Give themers as much flexibility as possible, without having to do major changes throughout Moodle.

Let them change the HTML output by the print_XXX functions in weblib.php.

Should we allow themes to have their own lang files and settings.php page in the admin tree?

==Design==

As I write this, we don't have a clear overview of the whole solution, but following some discussions, I have some ideas about how some components of the solution should work, and I want to write them down. Therefore, I present [[Navigation/Pagelib/Blocks 2.0 design|a possible (partial) design]]. (Real development never happens as they teach in Software Engineering classes anyway. ;-) )--[[User:Tim Hunt|Tim Hunt]] 23:28, 29 January 2009 (CST)

==Relevant tracker issues==

These come from a review of all the [http://tracker.moodle.org/secure/IssueNavigator.jspa?reset=true&pid=10011&resolution=-1&component=10088&sorter/field=issuekey&sorter/order=ASC&sorter/field=priority&sorter/order=DESC 'Theme' tracker issues].

* MDL-3625 $menu in header does too many things
* MDL-3626 header.html and footer.html $variable inconsistency
* MDL-8369 Folder-like presentation of the courses at the main page
* MDL-9306 Main course formats need to have tables removed but keep AJAX working - ''there seem to be some regressions from this work ;-)''
** MDL-12164 Hiding Course Topics and Switching Roles creates Problem in other Topics
** MDL-13410 Course view misaligned
** MDL-17450 Display of blocks and topic section not correct in 2.0
* MDL-10522 Hard-coded <br /> used for spacing.
** MDL-14058 Code includes <br /> tags in many places, which breaks theming, or makes it more difficult
* MDL-10681 Popup windows need uniform body class
* MDL-12093 It is not possible to change the page layout in popup windows
* MDL-12183 Improve block HTML structure
* MDL-12191 Let themes know whether this page has blocks.
* MDL-14061 Add category short names, and an option for categories in the breadcrumbs.
* MDL-14305 Class on body to identify the page as Moodle, and a specific site. (Enables sharing of stylesheets, but with a few specific customisations.)
* MDL-14306 The course category hierarchy should be reflected in CSS classes on the body tag (actually, contextids would let this be done more efficiently).
* MDL-14539 Replace table layout with div - ''parhaps a duplicate of MDL-9306.''
* MDL-14632 Increase use of tabs on all mod activities.
* MDL-14901 Themes can no longer control the separater used in the nav bar.
* MDL-15400 Sideblocks on "My Moodle" page not conforming to global width
* MDL-15817 Part course them and part site theme is used when displayng Outline and Complete reports
* MDL-15959 patch any theme to have a personal visual style (CSS file) for each course - ''not sure this is a good solution, but it is an interesting requirement.''
* MDL-16244 Support for a drop-down menu bar - ''Like on moodle.org now''.

==See also==

* [[Roadmap]]
* [http://moodle.org/mod/forum/discuss.php?d=108993 General developer forum discussion about templates]
* [http://moodle.org/mod/forum/discuss.php?d=95882 General developer forum discussion about blocks/pagelib]
* [http://moodle.org/mod/forum/discuss.php?d=115389 Forum discussion about having blocks on the category pages]

Conditional activities

2008-05-15T15:24:23Z

Ray: /* This activity will be available when ... */

This is a developer's page for Moodle Version 2.0, describing an evolving specification. UNDER CONSTRUCTION!

Conditional activities allow the course editor to hide certain activities until conditions on other activities have been met.

For example, a student will not see Assignment B until they have scored 80% or higher on Quiz A.

==Objectives==

# We want to know when activities are finished (for each user independently)
# We want to have this calculated automatically, but also manually if required.
# We want other some activities to be hidden until other activities are done.
# We want to "chain" these things into learning paths.
# We want the course page to remain fast.
# We want conditional activities to be optional.

[[User:sam marshall|sam marshall]] For us and no doubt other places, the 'activity completion' part of the system is still useful even if we are not using conditional activities for a course. We would then want a reporting interface so that tutors can see which tracked activities their students have/haven't completed. (And for course staff, obviously they would be able to see all students on the course in the same manner.)

==Overview==

There are two main approaches to this. For the discussion below let's use A to mean a source activity, and B and C to mean two activities that are only available when A is done.

Approach 1: The one used by activity locking is to place the UI to choose the conditions in B, so that it specifies the passing grades etc that are needed for A so that B is unlocked. This has advantages in that B can specify a different passing grade that C (both on the same A).

Approach 2: This places the logic in A, so that it defines when it is "done" any way it likes and B can just say "I'm available when A is done". The advantages here are that A can define "done" in any way it likes, and the configuration can be more subtle if the module wants it.

The approach described below actually combines BOTH these approaches so it should please everyone and allow the maximum flexibility.

==Interfaces==

===Site settings===

Admins can turn Conditional Activities on/off for the whole site.

===Course settings===

Teachers can choose between three states for a course:
# Conditional Activities off
# Conditional Activities Manual
# Conditional Activities Auto

===Course page===

For teachers
* Each activity will have an icon indicating the status, and clicking on it takes you to the activity settings (see below). These are also available as a tab from the main activity pages.

For students
* Colour icons (checkboxes) in red/orange/green down the side of the course format indicate the status of each activity
* In manual mode, these can be clicked on to toggle the status as required (so that students can manually keep track of what they've done).
* In auto mode, these icons are fixed

[[User:sam marshall|sam marshall]] Be very careful with colours. You mustn't use colour as only way of displaying information (accessibility). I'd suggest something like: For manual mode, use straightforward checkbox as above; For auto mode, use an icon as described but make these look different as well as different colour (I'd suggest grey crosshatching for unavailable, white (hollow w/black outline) for available but not done, green tick inside box for done-pass, red cross inside box for done-fail) and of course include alt text

[[User:sam marshall|sam marshall]] 'Manual' and 'Auto' modes maybe needs rethinking. I think this should be actually be a choice of 'disable system' (why? well, anyway), 'enable system', and 'enable system plus student progress'. These are equiv to off, auto, and auto+manual. The reason for this is that if you specify conditions for something you always want it to be 'auto' obviously. But, anything you didn't specify conditions for, it could be 'manual' (i.e. you want students to track progress on some things that are not trackable automatically, e.g. 'go and read this web link' (a link) or 'go and read the book we sent you' (a label)

[[User:sam marshall|sam marshall]] If this approach is adopted (or anyway for standard manual), it needs a way to turn off progress support per-activity, this could be in course_modules or whatever. For example you don't want to include a 'progress' box on something like a generic course forum that is available for the life of the course, or a course resources page that's similar, or a page about how to contact student support. We do this because in editing mode, our checkboxes include a tiny little eye icon next to them so you can hide them where they aren't needed. Maybe also appropriate to set defaults i.e. labels default to not having progress.

[[User:sam marshall|sam marshall]] At the OU we use an option that controls who sees the checkbox. Remember course:participate? YES IT'S THAT AGAIN. Not that it is really really desperately needed or anything. Ahem. But anyhow, we have a specific permission for who the progress system applies to, and this is checked with doanything=false. You might need something similar.

===Activity settings===

When the teacher is editing the activity settings for each activity, they see two parts to the page:

====This activity will be available when ...====

The UI here is standard for all modules. (Settings are stored in the '''course_modules_avail''' table.) It shows all the other activities in the course, and beside each of them are menus to choose from:
* Grade >= X (<, <=, >= and >)
* Viewed
* Completed (as defined by that activity)

[[User:sam marshall|sam marshall]] Should also include date as a condition. Would be stored in course_modules_avail
[[User:ray| Ray Lawrence]] Absolute dates or relative to the course start date?

[[User:sam marshall|sam marshall]] Maybe consider also an option for whether the activity is visible before it is available, greyed out with a 'This activity will be available when...' note, or not displayed at all.

====This activity will be completed when ...====

This UI shows optional settings for this activity to define when it thinks it is finished. (Settings are stored in '''course_modules_done''' table):
* Grade >= X (<, <=, >= and >)
* Viewed
* Something else (interface defined by module)

==Tables==

===course_modules_completion===
This table records the status of each user completing each activity module. It represents current state and is used to make the display of course pages very fast. It is updated whenever grades or modules change etc. See also [[Course_completion]] for course completion which is a separate system.

* id
* courseid - just here for speed
* cmid - FK to course_modules
* userid
* status - hide / not done / in progress / done fail / done pass
* timemodified

===course_modules_avail===
Records settings for availability
* id
* cmid - the activity that is defining the condition
* cmsourceid - the activity we are checking
* gradesign - <, >, <=, => etc
* gradecutoff
* views - boolean
* modulespecific - boolean

[[User:sam marshall|sam marshall]] I think modulespecific is difficult to handle here because it probably needs to be set per module (i.e. typically in the module settings page and stored in the module's main table). Suggest moving to the _done table.

[[User:sam marshall|sam marshall]] Eloy suggested we should only store conditions in one place (as opposed to the A/B above) but I see the possible need for several e.g. a quiz, you want one activity that shows if you get > 80% and another one that shows only if you get <80%. However I think this could still be simplified - how about putting the 'grade' stuff ONLY in this 'avail' table (so your choice for avail is basically always 'require the activity to think it's done, however it likes' but then you can additionally require a grade as well). So done = completed regardless of grade or anything else, but avail could be conditional on grade.

===course_modules_done===
Records settings for whether something is done
* id
* cmid
* gradesign - <, >, <=, => etc
* gradecutoff
* views - boolean

==Process==

Coming soon

==Issues to think about==

* How do we cope with circular references?
* We should remove conditions when activities are deleted - how does that affect things downstream?

==sam's picture==

This diagram shows sam's idea of how it should look/work, which is not quite the same as the original description above. It definitely isn't intended to be final in any way as features might need to be removed (or added or changed) etc. - I just did a diagram to illustrate my thinking.

[[Image:conditional.png|Possible interface diagram]]

==See also==
*Take a look at the [http://moodle.org/mod/forum/view.php?f=678 Conditional activities forum] at [http://moodle.org http://moodle.org].
*[[Activity_Locking]], a MoodleDoc page with table and descriptions of different conditional activity modules
*[[Score Lock]] a MoodleDoc page for another conditional activity module for 1.6
*[http://moodle.org/mod/forum/discuss.php?d=35488 forum discussion about Stuart Mayor's Conditional Activities], including Moodle 1.6 version
*[http://moodle.org/mod/forum/discuss.php?d=36697 Conditional activities at CICEI], running demo included as student, teacher and designer.
*[[Adding/editing_a_lesson#Dependent_on]] MoodleDoc page . The lesson activity settings in V 1.6 has a specialized dependency setting. Entering the lesson can be made dependent on the % (lesson questions) correct, time spent or completion of one other specific lesson.

*Tracker reference(s) for conditional development _____________

[[Category:Conditional activities]]

Outcomes

2006-08-11T09:53:37Z

Ray:

'''Feature description:''' Build on the keywords in 1.6 to provide metadata for all activities and courses, linkable to standard lists of metadata such as State-based learning outomes and curricula.

This page is an initial place to discuss options for storing and managing moodle metadata. These are just suggestions and are made by a person who does not know moodle internals.

There are several steps to managing a complex applications metadata:
# Document the key "Data Element Concpets" and their structure. This would include high-level concepts such as Course, Student, Teacher etc.
# Document data element properties associated with each concept. Properties should always be associated with a concept.
# Store this metadata in a metadata "registry", a centrally managed place to store metadata
# Create a system that allows users to modify and update metadata

There are several ways to approach this.

* There are metadata registry standards such as ISO/IEC 11179. This standard has a wide number of interpretations.
* There are other education metadata standards such as IMS global and the School Interoperability Framework (SIF)
* Once the metadata is stored in a consistant place and format, transforms can be made to extract portions of the metadata using reports or transforms
* A metadata registry can be the heart of a model-driven architecture

Most systems attempt to seperate the semantics from the representation of metadata.
# Semantics tell us the meaning of a data element but are free from version or constraints
# Represtations of the metadata tell us what table and column metadata appears in each version of Moodle and what the limitations are in a specification

Many metadata managment systems use a 3-part data element name:

ClassPropertyTerm

Were Class is the concept, property is a property of that concept and Term is a Representation term such as Count, Date, ID, Indicator, Text

For example:

CourseDescriptionText

==Questions==
* Where can we get a list of key moodle conceptual data elements and their definitions?

* How do we set up a data stewardship role so individuals take responsiblity for maintaining subsets of all the data elements?

* What should the highest level data elements be? Course, Enrollment, Organization, Person, Quiz

==See also==
* [[Metadata:MoodleCore]] LOM application profile for Moodle course
* [[Thing]] A root data element of a metadata registry
* [http://en.wikipedia.org/wiki/Metadata_registry Wikipedia entry for Metadata registry]
* [http://en.wikipedia.org/wiki/ISO/IEC_11179 Wikipedia entry for ISO/IEC 11179 ]
* [http://en.wikipedia.org/wiki/Data_element Wikipedia entry for Data element]
* [http://en.wikipedia.org/wiki/Representation_term Wikipedia entry for Representation term]
* [http://en.wikipedia.org/wiki/Data_element_name Wikipedia entry for Data element name ]
* [http://en.wikipedia.org/wiki/Data_element_definition Wikipedia entry for Data element definition ]

==Example of a K-12 education metadata registry for ==
* [http://education.state.mn.us/datadictionary Minnesota (US) Department of Education Data Dictionary]

[[Category:Future]]