Development:Conditional activities

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

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

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:

1. Conditional Activities off
2. Conditional Activities Manual
3. 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

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

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)

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.

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)

Sam marshall Should also include date as a condition. Would be stored in course_modules_avail

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.

• 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

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.

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.

See also

• Take a look at the Conditional activities forum at 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
• forum discussion about Stuart Mayor's Conditional Activities, including Moodle 1.6 version
• 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 _____________