Hello all (with "all" I kind of mean Sam),
I was just wondering whether it will be possible (in 2.0) to use a particular (set of) response(s) in a choice activity as a condition for making another course activity available?
If that would be possible, you could very easily set up differentiated courses where an initial choice activity (e.g. "Are you a beginner, intermediate or advanced ....") would create a custom build set of resources and activities for the learner. Sounds like a good idea to me.
Should I write a tracker issue for this?
Kind regards,
Hans de Zwart
Conditional activities: Using response in Choice activity as a condition?
by Hans de Zwart -
Number of replies: 6
In reply to Hans de Zwart
Re: Conditional activities: Using response in Choice activity as a condition?
by sam marshall -
Hi,
This is not possible at present. I don't think I implemented any custom completion options for a Choice activity so it probably just has View, which is a bit sucky. It would be good if there was a completion option for 'has answered the poll'; if somebody wants to contribute that, please do.
Unfortunately the architecture doesn't really support what you're trying to do in this case, though, which is a bit of a failing. Basically the system is as follows: when it comes to conditions there are 3 types available, grade conditions (on one or more grades having particular ranges), date conditions (on current date), and completion conditions (on whether or not another activity is 'complete'). These three types are more or less fixed.
The completion conditions however can depend on each module, for example for forum you can say it is complete when X things are posted. There are some standard ones which most modules support, like 'mark complete when viewed' or 'mark complete when user gets a grade in this activity'. But the point is, they are always binary ('complete' or 'not complete' - it uses this to show a tickmark on the page). So you can't have 'complete, and they chose beginner'.
However, all modules also support manual completion (tickboxes on the main page so that users can tick it when they think they have completed it). I have not tested (please do) but I think you can use this to achieve the beginner/intermediate/advanced as follows:
1) Create 3 labels, beginner/intermediate/advanced (note these don't have to be labels, feel free to use resource web pages that explain the options)
2) Turn on manual completion for these 3 labels
3) On the 'beginner' label, add conditional availability that it is only available if intermediate and advanced are not complete. Do the equivalent on the other two labels.
4) On your 'real' activities further on, add conditions on these labels (available only if 'advanced' is complete; that kind of thing).
In this way, the user will see the 3 options on the front page. Once they tick an option, the other 2 options will disappear and the relevant activities will appear. If they change their mind they can untick the 'Beginner' tickbox (or whichever one) and get back to the 3 boxes again.
Incidentally I can see that people are going to want the OR feature again (when combining requirements, currently only AND logic is available)... I think there's already a tracker issue for this. My position is that it would be better if 2.0 has a simpler system and we wait for real usage before figuring out how best to improve it in 2.1.
--sam
This is not possible at present. I don't think I implemented any custom completion options for a Choice activity so it probably just has View, which is a bit sucky. It would be good if there was a completion option for 'has answered the poll'; if somebody wants to contribute that, please do.
Unfortunately the architecture doesn't really support what you're trying to do in this case, though, which is a bit of a failing. Basically the system is as follows: when it comes to conditions there are 3 types available, grade conditions (on one or more grades having particular ranges), date conditions (on current date), and completion conditions (on whether or not another activity is 'complete'). These three types are more or less fixed.
The completion conditions however can depend on each module, for example for forum you can say it is complete when X things are posted. There are some standard ones which most modules support, like 'mark complete when viewed' or 'mark complete when user gets a grade in this activity'. But the point is, they are always binary ('complete' or 'not complete' - it uses this to show a tickmark on the page). So you can't have 'complete, and they chose beginner'.
However, all modules also support manual completion (tickboxes on the main page so that users can tick it when they think they have completed it). I have not tested (please do) but I think you can use this to achieve the beginner/intermediate/advanced as follows:
1) Create 3 labels, beginner/intermediate/advanced (note these don't have to be labels, feel free to use resource web pages that explain the options)
2) Turn on manual completion for these 3 labels
3) On the 'beginner' label, add conditional availability that it is only available if intermediate and advanced are not complete. Do the equivalent on the other two labels.
4) On your 'real' activities further on, add conditions on these labels (available only if 'advanced' is complete; that kind of thing).
In this way, the user will see the 3 options on the front page. Once they tick an option, the other 2 options will disappear and the relevant activities will appear. If they change their mind they can untick the 'Beginner' tickbox (or whichever one) and get back to the 3 boxes again.
Incidentally I can see that people are going to want the OR feature again (when combining requirements, currently only AND logic is available)... I think there's already a tracker issue for this. My position is that it would be better if 2.0 has a simpler system and we wait for real usage before figuring out how best to improve it in 2.1.
--sam
In reply to sam marshall
Re: Conditional activities: Using response in Choice activity as a condition?
by Tim Hunt -
Sam, how hard-coded is the fact that there are three types of condition (grade, date and completion)?
If I remember what you have said in the past, part of the reason there can only be certain types is for performance reasons. It has to be things where you can easily grab all the data for this user on this course in a few DB queries.
I suppose another way round would be to make an option in the choice module, where the choice is made from a particular scale. Then that choice could be reported to the gradebook, and then it could be conditioned on.
If I remember what you have said in the past, part of the reason there can only be certain types is for performance reasons. It has to be things where you can easily grab all the data for this user on this course in a few DB queries.
I suppose another way round would be to make an option in the choice module, where the choice is made from a particular scale. Then that choice could be reported to the gradebook, and then it could be conditioned on.
In reply to Tim Hunt
Re: Conditional activities: Using response in Choice activity as a condition?
by sam marshall -
Quite hard-coded, and yes, for performance reasons. The idea is that, in this case, it's doing hard-coded grabbing of not-hard-coded data (completion, which can be customised by modules) so there is still flexibility. Unfortunately that not-hard-coded data is restricted binary.
Adding another similar hard-coded area would be ok - for example in addition to completion data we could have say, 'choice data' so that each activity (if it likes) can set a per-user integer value, independent of the completion stuff. Like:
condition::set_choice($cmid, $userid, $value);
Something in module_features could define whether it uses this system and the choices that are available.
With that we could allow each module to define a number of arbitrary states, and provide a way to select them. But, yeah this is complicating an already-complicated system.
You can already do the grade trick with no need to use choice - sort of. Just use a regular quiz and assign the options to various grade values there. (So if you use 'Beginner' it scores you 10%, etc.) You can probably make it hide that grade from the actual student gradebook display...
--sam
Adding another similar hard-coded area would be ok - for example in addition to completion data we could have say, 'choice data' so that each activity (if it likes) can set a per-user integer value, independent of the completion stuff. Like:
condition::set_choice($cmid, $userid, $value);
Something in module_features could define whether it uses this system and the choices that are available.
With that we could allow each module to define a number of arbitrary states, and provide a way to select them. But, yeah this is complicating an already-complicated system.
You can already do the grade trick with no need to use choice - sort of. Just use a regular quiz and assign the options to various grade values there. (So if you use 'Beginner' it scores you 10%, etc.) You can probably make it hide that grade from the actual student gradebook display...
--sam
In reply to sam marshall
Re: Conditional activities: Using response in Choice activity as a condition?
by Hans de Zwart -
Thank you Sam for your quick and extensive reply! I like your workaround (and consider myself stupid for not thinking of that). I have to agree with you that it is a good thing not to make this too complicated. It already will be a difficult thing for many people to sort through. Your workaround makes many more things possible and wouldn't be too ugly either.
This discussion brings me to another point though: have you or Tim ever thought about how the conditional activities functionality and the grouping functionality have an overlap in what they accomplish for the end user? Both of them will allow an editing user to hide something for certain people and show it to others.
In an ideal Moodle world this functionality would be unified. Groups are notoriously hard for people to understand (they often cannot grasp that each module implements its own group functionality and that certain modules implement none).
If you would start again, then you probably would allow groups and groupings, create the possibility to make groups self-registrable if required for the course and plug the group(ing) information into the conditional activities allowing group(ing) membership as a condition. You could then remove the currently grouping functionality for each module. You would indeed need an "OR" for the conditions I would think.
I am quite sure this won't happen for 2.0
, but I do think it will be a very weak aspect of Moodle from a usability point of view (I know this is important to you two: I have always been very impressed with the usability of the things that Sam has programmed, e.g. the OU Wiki which sadly wasn't the chosen one, and have always wondered whether it is Sam or whether it is the software design process that the OU has implemented).
Is this something that was discussed (tangentially) in Prague?
Thanks for all the work,
Hans
This discussion brings me to another point though: have you or Tim ever thought about how the conditional activities functionality and the grouping functionality have an overlap in what they accomplish for the end user? Both of them will allow an editing user to hide something for certain people and show it to others.
In an ideal Moodle world this functionality would be unified. Groups are notoriously hard for people to understand (they often cannot grasp that each module implements its own group functionality and that certain modules implement none).
If you would start again, then you probably would allow groups and groupings, create the possibility to make groups self-registrable if required for the course and plug the group(ing) information into the conditional activities allowing group(ing) membership as a condition. You could then remove the currently grouping functionality for each module. You would indeed need an "OR" for the conditions I would think.
I am quite sure this won't happen for 2.0
Is this something that was discussed (tangentially) in Prague?
Thanks for all the work,
Hans
In reply to Hans de Zwart
Re: Conditional activities: Using response in Choice activity as a condition?
by sam marshall -
Thanks Hans!
I agree the group/grouping restrictions ('Group members only' and the grouping dropdown) should probably be included in the same mechanism. Maybe in Moodle 2.1! We didn't really think about it at the time, I'm afraid. (Bear in mind that, although we never released it as such, this stuff was actually also developed for our custom Moodle 1.9 - so from a local point of view, we wanted to avoid changes to other areas of the system.)
As for whether user interface on our stuff is 'me' (or Tim etc) or 'the OU process' the answer is a bit of both! In the case of OU wiki it was also based quite heavily on the structure of the old wiki too... Basically if I have designed something then usually I designed the interface, but at the OU we also do quite a lot of testing and of course have user responses as well, so when the interface sucks, I probably get told.
And I have to convince some internal 'client' that the proposal should be okay, too, before starting. In addition, there's a mindset thing: at the OU we know we have lots of students with differing levels of computer experience so we always try (note try...) to aim for an interface that is relatively easy even for people who aren't particularly familiar with advanced websites. That might not always be the case - some people find it hard to imagine users who aren't familiar with Facebook, Twitter etc, let alone those who might not think to use scroll bars.
I wasn't in Prague (because I am (a) neurotic, and (b) against plane travel) - Tim was though. I don't think this specific issue came up. It probably should be sorted out at some point post 2.0 though.
(By the way - at least most of these features aren't turned on by default, so the standard interface is still relatively simple, unless you enable the feature.)
--sam
I agree the group/grouping restrictions ('Group members only' and the grouping dropdown) should probably be included in the same mechanism. Maybe in Moodle 2.1! We didn't really think about it at the time, I'm afraid. (Bear in mind that, although we never released it as such, this stuff was actually also developed for our custom Moodle 1.9 - so from a local point of view, we wanted to avoid changes to other areas of the system.)
As for whether user interface on our stuff is 'me' (or Tim etc) or 'the OU process' the answer is a bit of both! In the case of OU wiki it was also based quite heavily on the structure of the old wiki too... Basically if I have designed something then usually I designed the interface, but at the OU we also do quite a lot of testing and of course have user responses as well, so when the interface sucks, I probably get told.
I wasn't in Prague (because I am (a) neurotic, and (b) against plane travel) - Tim was though. I don't think this specific issue came up. It probably should be sorted out at some point post 2.0 though.
(By the way - at least most of these features aren't turned on by default, so the standard interface is still relatively simple, unless you enable the feature.)
--sam
In reply to sam marshall
Re: Conditional activities: Using response in Choice activity as a condition?
by Hans de Zwart -
Thanks for your reply. I didn't know neurotics were disallowed in Prague
Well, at least the group/grouping thing is now on the agenda and can eventually appear on some roadmap... In the meantime I am really looking forward to the creative things that teachers will create with these conditional activities!
Cheers,
Hans