This thread is an extension and a consequence of
Improving the multianswer(cloze) question, a proposal
The new interface is available for testing at
http://132.208.141.198/moodle_head_exp/
login as moodle pw:moodle
Pierre
Pierre,
I see no way to delete a subquestion from a Cloze question using your new interface. Deleting its {#n} reference in the Question text does not delete it from the list of subquestions. It does not appear when viewing the Cloze question, of course, but then even if all the subquestions are answered correctly, it's impossible to get the maximum score.
Joseph
I see no way to delete a subquestion from a Cloze question using your new interface. Deleting its {#n} reference in the Question text does not delete it from the list of subquestions. It does not appear when viewing the Cloze question, of course, but then even if all the subquestions are answered correctly, it's impossible to get the maximum score.
Joseph
Joseph,
You are doing a good testing job
.
I am not sure that I will allow deleting subquestions because of the code.(it will necessitate renumbering all the subquestions to the last one.
Perhaps the last one could be deleted if empty.
Otherwise reuse already created ones.
However the grading process should account of the number of questions really used.This is a bug
and I will resolve it
Thanks
Pierre
You are doing a good testing job
.I am not sure that I will allow deleting subquestions because of the code.(it will necessitate renumbering all the subquestions to the last one.
Perhaps the last one could be deleted if empty.
Otherwise reuse already created ones.
However the grading process should account of the number of questions really used.This is a bug
and I will resolve itThanks
Pierre
However the grading process should account of the number of questions really used.This is a bug
and I resolved it
.
Pierre
and I resolved it.Pierre
Hi Joseph,
On the other thread you wrote
When one has a fairly large number of questions, each with its own number of answers, the screen gets really cluttered and it is hard to know where one is, despite of the questions and anwers being numbered. I will try to think of something to suggest to you.
The actual QuickForm Moodle version is not designed to handle a large amount of data like the one that could originate from many subquestions.
I have worked a partial solution that allows the user to have a "minimum" display.
Pierre
P.S. Perhaps the solution will be to let the user choose which elements he wants to display.
On the other thread you wrote
When one has a fairly large number of questions, each with its own number of answers, the screen gets really cluttered and it is hard to know where one is, despite of the questions and anwers being numbered. I will try to think of something to suggest to you.
The actual QuickForm Moodle version is not designed to handle a large amount of data like the one that could originate from many subquestions.
I have worked a partial solution that allows the user to have a "minimum" display.
Pierre
P.S. Perhaps the solution will be to let the user choose which elements he wants to display.
The multianswer editing interface is easily crowded once you edit more than 2 or 3 questions. The user need to control the display so it fits his needs.
So I proposed the following variations in the display.
The initial display sets for each questiontypes a minimum of answers field lower than the standard values. The answers increment is also minimum.
The answers instructions are not displayed initially, the user usually will have built simple questions before doing multianswer.
Note that the questiontype can be changed with a select element that is built on-the-fly listing questiontypes that are_useable_by_multianswer ($QTYPES_USEABLE_BY_MULTIANSWER).
If the feedback is set to TEXT and answer instructions to display .
You can get also a minimum display
Notice that the changing questiontype select element is hidden .
You can also hide the feedback in the minimum as in the regular displayto a more simpler interface.
The others parameters are for example the units for numerical questions.
Almost all the validation code is done and the questions are already useable. The main problem is to code the XML import-export with all the questions parameters .
Pierre
So I proposed the following variations in the display.
The initial display sets for each questiontypes a minimum of answers field lower than the standard values. The answers increment is also minimum.
The answers instructions are not displayed initially, the user usually will have built simple questions before doing multianswer.
Note that the questiontype can be changed with a select element that is built on-the-fly listing questiontypes that are_useable_by_multianswer ($QTYPES_USEABLE_BY_MULTIANSWER).
If the feedback is set to TEXT and answer instructions to display .
You can get also a minimum display
Notice that the changing questiontype select element is hidden .
You can also hide the feedback in the minimum as in the regular displayto a more simpler interface.
The others parameters are for example the units for numerical questions.
Almost all the validation code is done and the questions are already useable. The main problem is to code the XML import-export with all the questions parameters .
Pierre
I will modify the proposal so that it allows to edit the old (and new) questions with the old interface.
So user could have the best of the two worlds...
Pierre
So user could have the best of the two worlds...
Pierre
Pierre,
This sounds like a very good idea.
Joseph
This sounds like a very good idea.
Joseph
This seems to be progressing nicely. It would be great if more people could look at it and give us their opinions about whether this is a helpful change or not.
Do we have an issue in the tracker for this yet? I think we should now.
Pierre, would be useful to see the code changes you have made so far, so I can review them a bit and make sure they seem reasonable and are heading in the right direction. If you create a tracker issue for this, could you please attach a patch of the changes so far, even though I realise that they are not finished nor cleaned up. Thanks.
Do we have an issue in the tracker for this yet? I think we should now.
Pierre, would be useful to see the code changes you have made so far, so I can review them a bit and make sure they seem reasonable and are heading in the right direction. If you create a tracker issue for this, could you please attach a patch of the changes so far, even though I realise that they are not finished nor cleaned up. Thanks.
Hi Tim,
I will put a detailed description of the code flows in multianswer, multiplechoice, numerical and short (and regexp) as the conditions for a questiontype to be useable by multianswers in the developper docs before CVS anything.
The site address to see it in action (but sometimes with messages...) is given at the first posting of this branch.
Pierre
P.S. doing this, I discovered a lot on PHP and moodle questiontypes. This allow me to simplify greatly the new multifunction calculated code. The two projects are becomimg more or less synchronized as they are two multianswers questiontypes.
A good overview of the code flow has been put in the docs
http://docs.moodle.org/en/Development:Cloze_question_type
Pierre
http://docs.moodle.org/en/Development:Cloze_question_type
Pierre
Tim,
This project is an extension of the actual cloze and should be separated from the actual multianswer cloze type because as it allows the introduction of new question types, the actual cloze specific syntax is no more useful in the extended or new multianswer question type.
If it is considered as a normal extension of the actual and that you accept (after all the necessary verifications) that it could be included in the normal moodle code even if the display is not conventional , I continue.
If not ,
)
Pierre
P.S. in any case, I learned a lot and had great fun doing it
Thanks Joseph for your fidelity to this forum and long life to the regexp as it is on the to-do list of Tim.
This project is an extension of the actual cloze and should be separated from the actual multianswer cloze type because as it allows the introduction of new question types, the actual cloze specific syntax is no more useful in the extended or new multianswer question type.
If it is considered as a normal extension of the actual and that you accept (after all the necessary verifications) that it could be included in the normal moodle code even if the display is not conventional , I continue.
If not ,
- as this question type needs the modification of the question_qtype_edit_form that are used, it is not a plug-in question type
- and there is no use to put in the contrib because of its interference with the code of many question type (although as designed it is transparent to the question types when use normally) .
- there is no plan to modify question_qtype_edit_form either in the internal code or in the display options
)Pierre
P.S. in any case, I learned a lot and had great fun doing it
Thanks Joseph for your fidelity to this forum
and long life to the regexp as it is on the to-do list of Tim.
I think the work you have done is really useful investigation into how to solve this particular problem. Unfortunately, I really don't have time to think about it in sufficient depth at the moment, and these are necessarily big and complex changes. It is important to find the right solution to this fairly complicated problem, so if anything we need more experimentation before we can think about getting a solution to this into core.
I think that some of the other projects you are working on are more likely to get us more intimidate benefits more quickly. So probably the right thing to do is to put this one to one side for now and concentrate on them.
However, before you do, I think it would be really great to put this code somewhere publicly accessible. Even if I don't get the time to look at it, at least the other people can. Or if I do get some time, it is then easy for me to grab it.
Fortunately, there is a space available for this. In contrib, as well as cvs:/moodle/contrib/plugins/, which is for nice, self-contained things, there is also cvs:/moodle/contrib/patches/, which is designed for larger, messier changes that affect several areas of the code. I think you should archive your code there for now.
I think that some of the other projects you are working on are more likely to get us more intimidate benefits more quickly. So probably the right thing to do is to put this one to one side for now and concentrate on them.
However, before you do, I think it would be really great to put this code somewhere publicly accessible. Even if I don't get the time to look at it, at least the other people can. Or if I do get some time, it is then easy for me to grab it.
Fortunately, there is a space available for this. In contrib, as well as cvs:/moodle/contrib/plugins/, which is for nice, self-contained things, there is also cvs:/moodle/contrib/patches/, which is designed for larger, messier changes that affect several areas of the code. I think you should archive your code there for now.
Fortunately, there is a space available for this. In contrib, as well as cvs:/moodle/contrib/plugins/, which is for nice, self-contained things, there is also cvs:/moodle/contrib/patches/, which is designed for larger, messier changes that affect several areas of the code.
Unfortunatety this is not a nice self-contained things and neither a patch but a complete project of extending the functionality to question_qtype_edit_form.
Alas even if you wrote
"This seems to be progressing nicely. It would be great if more people could look at it and give us their opinions about whether this is a helpful change or not."
and you also wrote
I would also add, that I have been slightly disappointed how little discussion of the 3rd-party question types that are available in this forum.
A little more than slightly but perhaps Moodle with all his new complexity and its use by large universities is at a crossroad about community development.
So I just wrote else where on the forum (http://moodle.org/mod/forum/discuss.php?d=85417)
I come back to the calculated question type
Pierre
Unfortunatety this is not a nice self-contained things and neither a patch but a complete project of extending the functionality to question_qtype_edit_form.
Alas even if you wrote
"This seems to be progressing nicely. It would be great if more people could look at it and give us their opinions about whether this is a helpful change or not."
and you also wrote
I would also add, that I have been slightly disappointed how little discussion of the 3rd-party question types that are available in this forum.
A little more than slightly
but perhaps Moodle with all his new complexity and its use by large universities is at a crossroad about community development.So I just wrote else where on the forum (http://moodle.org/mod/forum/discuss.php?d=85417)
I come back to the calculated question type
Pierre
I will probably put the code on my Source Forge Moodle at chemistry UQAM
A good overview of the code flow has been put in the docs
http://docs.moodle.org/en/Development:Cloze_question_type
And the new interface is available for testing at
http://132.208.141.198/moodle_head_exp/
login as moodle pw:moodle
Pierre
A good overview of the code flow has been put in the docs
http://docs.moodle.org/en/Development:Cloze_question_type
And the new interface is available for testing at
http://132.208.141.198/moodle_head_exp/
login as moodle pw:moodle
Pierre
In reply to Pierre Pichet
Re: Clozing the new multianswer(cloze) question project ?
by Anthony Borrow -
Pierre - I had dropped your reply in my followup folder - probably as a reminder to myself to follow up and see if you wanted to maintain this code in CVS - CONTRIB. If so, you know where to find me. Peace and Merry Christmas - Anthony