unify all activities and resources

Jump to: navigation, search

This is a general set of ideas that I hope could be considered for Moodle 3.0 (or sooner, if possible). In essence, it is a refactoring of activities and resources to allow for more code re-use and more flexibility in how activities and resources are used.

In this document, Activity is a general term that indicates an item within a Moodle course, which may be based on a reusable template. (Templates represent earlier activity types such as Assignment, Forum, Quiz, etc., and can be shared between Moodle instances.) Updates to the Template can update all Activities based on that Template. (See existing Database Template Presets) See Dataform plugin for some helpful feature descriptions (and possibly code).

This is intended as an early working draft, with the hope that others will comment and improve it.

Rationale

Currently there are many different kinds of activities and resources, with varying features, some of which would be desirable in other activities. For example, ratings could be used by students to give feedback on faculty-posted resources. Rubrics could be used in grading Forum discussions. The Allocation features of Workshop could be helpful in the Assignment activity.

Some of these activities, like the Quiz activity, implement plugins for question types and behaviors, but these can't be used in other, similar activities.

Yet, all of the activities and resources are just different variations on databases. It is easier for most instructors to use pre-constructed activities like the current Quizzes or Assignments, but these could be implemented as templated presets of a new, super-database activity. This is what is proposed below.

Contexts

This proposal extends the existing Context hierarchy as follows:

  1. Site
  2. Category
  3. Course
  4. Section
  5. Activity
  6. Record
  7. Interaction
  8. Submission
  9. Advanced Grading

When a backup is made of a Course, each subsequent level can be optionally included or excluded. For example, a backup might include all contexts to the Interaction level, but not include Submissions (formerly designated as "user content"). At another level, an Activity might be backed up, including Record definitions, but not including any Records. This would be used, for example, to back up a Forum definition for use in the next instance of the course.

Activities

Each Activity defines the following (all implemented as plugins where possible):

  • Context: the level at which data for the Activity is stored, e.g. Section, Course, Category, Site, etc.
  • Scope: the level at which data for the Activity is unique, e.g. Section, Course, Category, Site, etc. For example, an Activity could be added to every Course on the site, but its contents could vary per individual Course.
  • Activity Fields including title, description, icon image, etc., with options to display each on the Course Page.
  • Search constrained by Context/Scope
  • Grade aggregation calculation(s) (allowing calculations including sums, averages, and counts of record grades and submission grades) – more than one can be defined for an Activity, resulting in multiple entries in the Grade Book for different aspects of an activity (e.g. the way the current Workshop provides two grades per student). Includes “drop lowest n” options to allow alternate assignments.
  • Completion aggregation: calculation to determine whether the Activity is “Complete” for a given Student, based on “completion” of a defined number of individual Records.
  • Selection Criteria of records to display to a given user, or for a given session, e.g. a selection of quiz questions, chosen randomly, or the 5 most highly rated items
  • Navigation Rules that define what displays when the user enters the Activity (e.g. first record using a Display, other record using criteria, a Report), and how a user with a particular role is able to select the next record(s) to view. Also includes Progress Indicator.
  • Record Display Formats allowing organization and theming of record data display, including incorporation of Label and User Profile data, as well as auto-display of the contents of a single Field (e.g. downloading a file or visiting a URL). E.g. Dataform
  • Reports defined with a form-based interface or via SQL, made visible by role and/or group, to summarize records and interaction responses, which can also be displayed directly on the Course Page
  • Submission Settings, including Group submission settings, and including whether Interactions can be updated, by which Roles or Groups
  • Notifications when records are created or updated, or when a Submission to an Interaction occurs, or based on field data (e.g. a reminder notification based on a date entered by a student). Notifications include Subscription management. Users can subscribe to updates based on record creation, update, comment, etc.; types of subscriptions available are controlled by the Activity designer.
  • Availability criteria, Access Restrictions, Visibility (consolidation needed) Includes distinction between Read/Write and Read only, and can change at time based from course start/end, also includes maximum entries and minimum entries before view, and Approval roles/groups
  • Grouping Selection and Mode
  • Block Option: includes selection criteria for display of data from records in a Block by Context.
  • Auto-Link Option: Provides automatic linking within a Context to records based on a match to a specific Field.
  • Revision Control
  • RSS Generation

Examples of Activities

All current Activities and Resources are examples of activities (see below for how existing examples would be implemented using this system).

Records

Activities consist of a collection of one or more Database records, each with the following features:

  • Record Fields storing any of a number of data types per record.
  • Entry States and permissions to change them (replacing Approval Criteria) by Role and Group (See https://moodle.org/mod/forum/discuss.php?d=244681)
  • Uniqueness Criteria: which fields or combinations of fields must be unique within the database per record
  • Grades (including Ratings as an Advanced Grade type) assigned at the Record and Interaction Response level, weighted by role(s)
  • Actions that occur as a result of user behavior (creation of records, submission of responses matching a pattern, receipt of specified grades, etc.)
  • Tags with permissions to view or alter by role
  • Usage statistics which can span sites

Examples of Records

  • Forum Posts
  • Glossary Entries
  • Database Records
  • Assignment Description
  • Blog Post
  • Quiz Questions
  • Questionnaire Questions
  • Wiki Pages
  • Book Pages

Interactions

A Record can contain one or more Interaction fields, (e.g. file uploads, multiple-choice questions, etc.) that accept Submissions from users. Includes Comments as an Interaction type.

  • Each Interaction is attached to a table of Submissions. It is possible to aggregate and analyze data from all Submissions to a given Interaction across all its uses (multiple Activities, Courses, even Servers).
  • Selectable from Interaction Pools as Instances or Copies.
  • Interactions also implement psychometric data/history attached to one or more Competencies. This attachment is necessary because the discriminant value of an item cannot be determined outside of the context of the Competency it is designed to measure.

Examples of Interactions

  • Forum Post Attachment Feature
  • Database Fields
  • Blog Post Comment buttons
  • Quiz Question Types
  • Custom Label (Course Element) Templates
  • Rating Features
  • Stamp Collection Features
  • Assignment File Attachment Boxes
  • Folders for File Attachments


Submissions

  • Each Submission records the user, date and time, and the action the user took.
  • Interaction submissions can be exported to Portfolios or can be otherwise published by the learner or others with permissions.
  • Interaction Submissions are not normally copied with a course; they are treated in the same way as "user data" in Moodle currently.

Examples of Submissions

  • Forum Post Comments
  • Blog Post Comments
  • Quiz Submissions
  • Assignment Submissions
  • Guestbook Entries
  • Ratings
  • Choice Submissions
  • Questionnaire Submissions

Grading Methods

As current Advanced Grading plugins.

Examples of Grading Methods

  • Rubrics

Migration from Existing Activities

Existing Activities and Resources would be implemented as Uber-Activities, and full migration support would be provided:

  • Assignment: As currently implemented (2.3-2.5), a single-record database containing a single Interaction, usually specified as a file upload, optionally adding Interactions of Text Boxes. Includes submission settings, notifications, and a Grading Method.
  • Blog: A simple database with RSS generation
  • Certificate: A single record containing a Display that incorporates User Profile information
  • Chat: Implemented as an Interaction type, with logging. Each session creates a new record.
  • Choice: A single record with a single Interaction, the Submissions of which can be made visible to Users by Role
  • Database: An activity with multiple records, but no Interactions
  • External Tool: A single record containing a single Interaction that implements LTI (an Interaction Type plugin)
  • Forum: Each Post is a record, with comments turned on. Ratings are enabled for both Records and Comments. Reports provide the ability to switch between threaded and flat views, etc. Notifications are available.
  • Glossary: A Database format with pre-defined Record displays and Reports. Auto-Link is enabled.
  • Lesson: A Database of content with Interactions, and Navigation actions based on Interaction results.
  • Questionnaire: A Database of simple Interaction records, with results compiled using a Report, visible by role. Navigation can display all records on one page or broken into separate pages.
  • Quiz: A Database of Interaction records. Interactions (plugins) are used to implement existing Question Types. Actions increment a “grade” variable based on Interaction Responses, and can display messages immediately (per record) or in a report, by role, and based on Submission Settings. Navigation can display all records on one page or broken into separate pages.
  • SCORM package: A single record implementing SCORM support as an Interaction, with an attached file containing the SCORM package.
  • Survey: A predefined Questionnaire, made available at the Site level.
  • Wiki: Database records, primarily consisting of a Text Box using Filters to implement Auto-Linking. Text box allows standard formatting.
  • Workshop: Database of single Interaction record, much like Assignment; role-based permissions allow Groups of users with particular Role to grade using Advanced Grading type plugins. Custom Grade Aggregation Calculations define grading quality and individual assignment quality as separate Grade Book entries.
  • Book: A set of Pages (minimalist Records-- see below) with TOC Block navigation (a Block that displays automatically when in the Activity). Custom titles are an additional Field. Next, Previous, and Up navigation is provided as part of the Record Display, based on simple Parent and Display Order values.
  • File: A simple one-record database with a file attachment (not an Interaction), only editable by the Instructor.
  • Folder: A multi-record database in which each record allows one file attachment, only editable by the Instructor, with a Report displaying all entries.
  • IMS Content package: A single-record database implementing IMS support as an Interaction.
  • Label: A minimalist one-record Activity consisting of a block of formatted text that is displayed on the Course Page.
  • Page: As currently implemented, this is a minimalist Activity containing Title, Description, and Content fields, with no Interaction. Obsolete: see “Subpage.”
  • Subpage: A Navigation Method outside of Activities; a link to an otherwise hidden Section, which can contain Activities.
  • URL: A minimialist Activity containing Title, Description, URL, variables (may be pulled from Contexts) and Auto-Display criteria.

Additional features

  • Interaction instances can be shared between servers/institutions, i.e. public question pools. Anonymized psychometric data is attached.
  • Interaction submissions can be aggregated by Learners and sorted by Competency, tags, etc. and can be published by Learners such that permalinks provide access to prospective employers, other educational institutions, etc., and can be referenced by Open Badges
  • Export/Import capabilities
  • Possibly many kinds of Blocks could be implemented this way, as well. A flexible reporting Block type would provide equivalent functionality to many core Blocks, especially if it could draw on various user profile fields and course fields.
  • Making it possible for a site administrator to add custom metadata fields to courses (similar to custom Profile fields) could also make a flexible plugin system more powerful.