Development:Conditional activities: Difference between revisions

From MoodleDocs
Line 47: Line 47:
* In auto mode, these icons are fixed
* 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 displaing information (accessibility). I'd suggest something like:
[[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
 
* 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]] '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.
[[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.


===Activity settings===
===Activity settings===

Revision as of 09:59, 17 April 2008

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.

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.

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. This may complicate the design slightly as obviously date is not a per-other-activity option

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)

Sam marshall Just wondering, how are you going to track 'viewed'? Modules don't store this in a sensible way, only in the log table.

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_completion

This table records when whole courses are completed.

  • id
  • userid
  • courseid
  • status

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

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?


See also

  • Tracker reference(s) for conditional development _____________