Stealth mode and nested activities
This is a proposal for something that might go into Moodle 2.0.
We have had a version of this feature in our customised OU Moodle for some time (doing live date, remove date, and a basic version of stealth mode). We are about to enhance how it works (following the design below). We would like to contribute this to Moodle core, but that would need Martin D's approval. As you can see from the requirements section, several other people want this feature.
Requirements
- Have an activity that is accessible to students, but not listed on the front page. (Presumably the course creator will put a link to the activity somewhere else in the course.) This is sometimes called 'stealth mode'.
- Where an activity is not listed on the course page, but is instead only available via a link elsewhere, reflect the path to the stealthed activity in it's navigation trail.
- Have an activity that does not appear to students until a given date, or which automatically disappears after a given date. This is sometimes called 'live date' and 'remove date'.
Design
Note, the mock-ups below use the the OU Moodle theme, and an ou-specific course-format, but they should be clear to people used to the standard theme too.
How it looks to users
It will still be the case that all activities have to be added to the course front page. So, when you are editing the course, things will look just like they do now:
Note, nowever, that activities that are not visible to 'students' now (assumed to be 3rd October) have red annotation text explaining this. In the previous sentence I say 'students' in inverted commas, because the hiding actually takes effect when editing is turned off. So with the example above student and guests, and teachers and adminsitrators when editing is turned off, will see:
How is this controlled? By some extra fields in the 'Common module settings' section of the activity settings form - the middle three settings below are new:
To simply hide an activity from the front page, you must assign it a parent activity. If an activity has no parent, then it will be visible on the course page. If it has a parent, then it will be hidden from the course page. In addition, when you are looking at that activity, then the navigation bar will be modified, to show where the activity fits. For example, in the example above, the resource 'Extra information used by the quiz' will have this navigation bar:
(Just to reinforce the point, the Quizzes link is there, and the Resources link isn't.)
The Available from and Unavailable from dates do more than just hide the module from the front page. If an available from date is given, then the activity will not be visible, nor will it be accessible, even if you type the URL, before that date (unless you have the view hidden activites capability). On that date, it will appear (unless the standard visibility setting is set to hide, or it is stealted) and it will be accessible to everyone (unless visibility is hide). If an unavialable from date is given, then it goes back to being unavailable from that date. Note that the editing form will ensure that the available from date is before the unavailable from date, if both are given.
Note that the stealth hiding of activites only applies to the course front page, not the activity index page. For example, in the example above, the Resources index page will look like:
Because activites are still created on the front page in editing mode, it is clear which section and whic order they appear in on the index pages. Similarly, no change will be made to any other place activities are listed (for example custom blocks).
Note that there will be no automatic navigation built from a parent activity to the child activities. As meantioned above, it will be up to the teacher to create these links. This is because the best place for the link depends on the particular activity. For example, for one quiz, you may want the link to appear in the introduction. In another quiz, you might want it to appear in the overall feedback.
If an activity that is a parent of other activities is deleted, then the child activities will not be deleted. Instead the child activities will have their parent set back to none.
Nested parent activities do not affect roles and capabilities. The parent context of each module context will still be the course context, as at present.
So, to sumarise: On the one hand, stealth mode/parent activities lets you hide activities from the coures home page while still having them available to students; and on the other hand available and unavailable dates let you essentially automate changing visiblity from hide to show and back to hide.
Implementation
Database changes
The three new settings will be stored in three new columns in the course_modules table:
| Field | Type | Default | Info |
| livedate | int(10) | NULL | a timestamp, if set, the activity is not available until this time |
| removedate | int(10) | NULL | a timestamp, if set, the activity is not available after this time |
|---|---|---|---|
| parentid | int(10) | NULL | if set, a reference to the id of another row in this table with the same course |
When the database changes are done, these three new columns will all initially be set to their default values for all rows.
(Note that the upgrade is more complicated in OU Moodle, where some of this data already exists, sometimes in other places.)
Editing form changes
Discussion
The features proposed here are certainly open to abuse. By misusing them, it will be much easier to make courses that are totally confusing for students.
However, there are valid use-cases where correct use of these features will let people make courses that are better structured.
If people choose to ignore the three new settings on the module forms, then Moodle will continue to function exactly as it does now.
Therefore, on balance, I think these feature should be included in Moodle 2.0. We should include a discussion of appropriate use and abuse of these features in the help, or on Moodle Docs. (Not that anyone will bother to read it.)
