What are all the bits of a Moodle question

What are all the bits of a Moodle question

by Tim Hunt -
Number of replies: 19
Piksa bilong Core developers Piksa bilong Documentation writers Piksa bilong Particularly helpful Moodlers Piksa bilong Peer reviewers Piksa bilong Plugin developers
Working on my question engine re-write, I have been trying to get my head around what all the different bits of a Moodle question are.

I need to know this, so I can make the code work correctly, but more importantly, there needs to be a clear answers so that it is possible to explain how the quiz works to teachers and students.

This diagram summarises my attempts:

Parts_of_a_question.png

There is a more detailed explanation on Development:Question Engine 2:Overview#What_are_the_parts_of_a_question.3F.

However, I am sure I have overlooked something, so I am posting here in the hope of getting some comments.
Average of ratings: -
In reply to Tim Hunt

Re: What are all the bits of a Moodle question

by Pierre Pichet -
As always numerical or calculated are modifying somehow the design.wink

screenshot

Two answers field and some specific infos

Pierre

In reply to Pierre Pichet

Re: What are all the bits of a Moodle question

by Tim Hunt -
Piksa bilong Core developers Piksa bilong Documentation writers Piksa bilong Particularly helpful Moodlers Piksa bilong Peer reviewers Piksa bilong Plugin developers
That fits into the above general framework, doesn't it?
In reply to Tim Hunt

Re: What are all the bits of a Moodle question

by Pierre Pichet -
This can be handled in the general framework as long as numerical can control as in the actual code, the placement of the necessary features not necessarily at right of the input elements but below as the instructions field.

The calculated can use the numerical display i.e. the numerical renderer which is becoming different from the short answer for that part that shows the input elements.

In the 2.0 the units can be shown at left (like $) or at right of the number input elements with three variant either a simple text unit display, the input element as shown or multichoice radio elements.

The cloze should remain a special case with all the actual variants even if some parts are not completely conform to disabled students (feedback from pop-up windows).

Pierre



In reply to Pierre Pichet

Re: What are all the bits of a Moodle question

by Pierre Pichet -
Just notice that this unit display is on HEAD not 1.9 ,

Pierre


In reply to Tim Hunt

Re: What are all the bits of a Moodle question

by Oleg Sychev -
Piksa bilong Core developers Piksa bilong Plugin developers
Tim, you are dropped some pointers that new engine will support hints. What are their place in that picture? Who will control them - question engine or interaction model?
In reply to Oleg Sychev

Re: What are all the bits of a Moodle question

by Tim Hunt -
Piksa bilong Core developers Piksa bilong Documentation writers Piksa bilong Particularly helpful Moodlers Piksa bilong Peer reviewers Piksa bilong Plugin developers
The OU has an implementation tied up with our interactive mode. That would make it a feature of the interaction model.

Basically, there is a question_hints table, a bit like question_answers. There are a set of form fields on the editing form for most question types to input the hints. Then, each time the student submits a wrong answer, they get shown the next hint - I think it is shown just after the specific feedback.

However, hints could also be implemented as more of a question type feature. Actually, we have a bit of that. For example, in the matching question, as well as the textual hint, you can also choose whether the student's wrong answers are cleared.

I have not worked out the details of what I will do in the new system yet.
In reply to Tim Hunt

Re: What are all the bits of a Moodle question

by Oleg Sychev -
Piksa bilong Core developers Piksa bilong Plugin developers
I guess there should be two types of hints (like feedback): general (tied up either with student choosing to use hint or on each next given response in adaptive mode) and question type dependednt hints (like joseph's regex hint of the next character).

One of the possible problems would be to avoid bloat ing question editing form (which isn't small already) adding hints (or other interaction-model specific data) editing.

Also having a category of similar questions I would often like to share hints between them, to avoid endless copying of one text (or, at least, an ability to point several questions to one set of hints).

Also I vaguely remember you telling interaction model shouldn't have own data, which somewhat in conflict in implementing hints using it.

The best possible my guess for now is that every question form should have a section or page (probably popup) for interaction model-specific data (and one question could store data fot several interaction models).

I think if a problem of interaction model storing (and editing) per-question data would be solved, it would also open an easy way to integrate question bank with lesson module (i.e. adding interaction model to store/execute jumps). Or even a quiz with new interaction model could behave like a lesson...
In reply to Tim Hunt

Re: What are all the bits of a Moodle question

by Pierre Pichet -
An example from a recent forum of the most current use of cloze i.e text analysis which show how much this will not fit in the usual case.

Extra linebreaks in Cloze

cloze example

and this does not include select multichoice or the more "regular" display of multichoice.
The feedback and goor response are displayed in a pop-up window which appears when the mouse is over the input element .

At first sight , it seems easier to use a code flow similar to the actual code than the general new engine code flow.
Either the new code is copied in the cloze code or link to part of it, is not clear.

Pierre

P.S. I put this reminder for those not familiar with cloze.


In reply to Pierre Pichet

Re: What are all the bits of a Moodle question

by Tim Hunt -
Piksa bilong Core developers Piksa bilong Documentation writers Piksa bilong Particularly helpful Moodlers Piksa bilong Peer reviewers Piksa bilong Plugin developers
That does fit in with the general picture, if you can read my mind wink

The whole block at the top of my diagram (question text, controls belonging to the qtype, and perhaps some specific feedback) are actually a single unit that is output by the question type, and that whole block can mix those three things up as much as it likes.
In reply to Tim Hunt

Re: What are all the bits of a Moodle question

by Pierre Pichet -

"The whole block at the top of my diagram (question text, controls belonging to the qtype, and perhaps some specific feedback) are actually a single unit that is output by the question type,"

So in the green block, the yellow part is what the actual cloze output in the pop-up window.

Could we, in the cloze case, transfer other items of the yellow bottom block to the yellow upper part of the green block (as grading details for subquestions that are not displayed in the actual version)?

Have a plentiful colored "Halloween" wink.

Pierre


In reply to Tim Hunt

Re: What are all the bits of a calculated question

by Pierre Pichet -
Hi Tim,
Working on your test engine code for calculated, I try to figure where in your schema the values of the {params} should be subtituted in the question text .

Is init_first_step() in question definition the place to do it?

Pierre
In reply to Pierre Pichet

Re: What are all the bits of a calculated question

by Tim Hunt -
Piksa bilong Core developers Piksa bilong Documentation writers Piksa bilong Particularly helpful Moodlers Piksa bilong Peer reviewers Piksa bilong Plugin developers
Yes, init_first_step is key.

I think the best example code to look at so far is http://github.com/timhunt/Moodle-Question-Engine-2/blob/new_qe/question/engine/testquestiontype.php#L229

That is the code where it randomises the order of choices in a multiple-choice question.

Look at the else branch. This is where we do the randomisation to set up the question class ($this->order = ...), and record the choices made using $step->set_qt_var(...). For calculated I think you should be choosing the value for each of the question {params} here.

The 'else' branch is what happens when a question is being started for the first time. The 'if' branch is what happens later when we need to resume an already-started question using data from the database.

In the if branch, we set up the internal state of the of the question using $step->get_qt_var(...).


But as for where you should replace the {params} in the questiontext with the values taken from $this->params? It feels more natural to me to do that in the output function. Hmm. Perhaps I have not thought about it fully. It could work out better to do it in init_first_step. I'm not sure.
In reply to Tim Hunt

Re: What are all the bits of a calculated question

by Pierre Pichet -
In the actual code this is done
print_question_formulation_and_controls(&$question, &$state, $cmoptions, $options) {
// Substitute variables in questiontext before giving the data to the
// virtual type for printing (can be numerical or multichoice)
$virtualqtype = $this->get_virtual_qtype( $question);

// We modify the question to look like a numerical or multichoicequestion
$virtualqtypequestion = fullclone($question);
if ($question->options->multichoice == 1 ) {
foreach ($virtualqtypequestion->options->answers as $key => $answer) {
$answer->answer = $this->substitute_variables($answer->answer, $state->options->dataset);
...
}else {

foreach ($virtualqtypequestion->options->answers as $key => $answer) {
.....
}
$virtualqtypequestion->questiontext = $this->substitute_variables(
$virtualqtypequestion->questiontext, $state->options->dataset);
// then
$virtualqtype->print_question_formulation_and_controls($virtualqtypequestion, $state, $cmoptions, $options);


Is your class question definition is just for testing or will we create a question_definition ?
Also
public function get_renderer() {
if (?? ->multichoice == 1{
if ($single)){
return renderer_factory::get_renderer('qtype_multiplechoice', 'single');
} else {
return renderer_factory::get_renderer('qtype_multiplechoice', 'multiple');
}

}else {
return renderer_factory::get_renderer('qtype_numerical');
}
}

So when using the renderer, there will be a test for each renderer function to define which code to apply ??

Pierre

P.S.
$virtualqtypequestion is written $numericalquestion in the actual code. Writing this post, i realize that it should be written as $virtualqtypequestion when cleaning the codewink. We have to set if we create or not a 'calculatedmultichoice' qtype.

P.S.2 Having two renderers for multichoice means that if the teacher modify the multichoice single or multiple option for a multichoice question already is a quiz this could scramble the attempt data. There should be a warning in edit_multichoice_form as I have done for cloze.



In reply to Tim Hunt

Re: What are all the bits of a Moodle question

by Phil Butcher -
Tim,
A few thoughts to start with.

First of all do we need to lay out how marks and penalties are combined within the main text? Can we not shorten this and move it to the left hand panel? It is also the case that the scoring for any question with multiple parts and multiple tries soon gets far too complicated to explain in depth - so let's radically shorten it.

Secondly I'm assuming that hint/feedback that is to be followed by a further try will appear in the bottom-right yellow area. But it might be good to be clear.

Thirdly I wasn't clear if the items are laid out in the order they would appear? I ask because Specific feedback, if written well, will flow into General feedback and consequently they should be together.

Phil
In reply to Phil Butcher

Re: What are all the bits of a Moodle question

by Tim Hunt -
Piksa bilong Core developers Piksa bilong Documentation writers Piksa bilong Particularly helpful Moodlers Piksa bilong Peer reviewers Piksa bilong Plugin developers
Those are certainly all good questions.

1. I don't know how much explanation of the mark we want. I can see strong advantages in saying less. It is just in situation like adaptive mode (where we currently have a rather strange explanation) and perhaps the new certainty based marking, where we might need some explanation. If you look at the slightly longer explanation on the wiki page http://docs.moodle.org/en/Development:Question_Engine_2:Overview#What_are_the_parts_of_a_question.3F, you will see that whether the detailed explanation appears will be optional. At least that is my current thinking.

2. Yes, I would count those as specific feedback. I suppose the question is, should the try again button be in the yellow area, or the blue? I guess logically it should follow the explanation, so be in the yellow area.

3. The order was a proposal, but I was not sure it was right. I take your point about general feedback straight after specific feedback.
In reply to Tim Hunt

Re: What are all the bits of a Moodle question

by Tim Hunt -
Piksa bilong Core developers Piksa bilong Documentation writers Piksa bilong Particularly helpful Moodlers Piksa bilong Peer reviewers Piksa bilong Plugin developers
OK, here is a revised sketch:

Parts_of_a_question2.png

Below is the list of settings that control what is visible. These are settings passed around within the code to control rendering. They don't necessarily map directly onto user-interface settings.

The way it will work is based on the settings the teacher has set up for the quiz (as an example - questions can appear elsewhere) it creates a question_display_options object with the appropriate settings.

Then the interaction model gets to adjust the settings, depending on the state the question is currently in. For example, if the student has not yet submitted an answer, the interaction model will turn off all the feedback options, or after the student has submitted their final answer, the interaction model will ensure the question only appears in read-only mode.

correctness (hidden / visible) whether the student gets told whether their answer was (in/partially)correct in the status summary under the question number, or instead are told something vague like 'Finished'.

marks (hidden / max only / actual mark and max / actual mark and max with explanation ) whether the student can see the number of marks available, and how many marks they got, and how much detail of the marking to display.

marks d.p. (0 .. 7) how many decimal places marks are displayed to.

flags (hidden / visible / visible and editable) this is the feature that lets students bookmark or flag a question in an attempt for later reference.

read only Whether the question just shows the response was already entered, or whether it gives controls to the user enter/change their response.

specific feedback (hidden / visible) feedback that relates to the particular response the student entered.

general feedback (hidden / visible) whether the general feedback (same for all students) is visible.

correct response (hidden / visible) whether the automatically generated message or other indication of the correct answer is visible.

manual comment (hidden / visible / visible and editable) whether the comment manually added by the teacher is visible and editable by the current user.

response history (hidden / visible) whether the list of steps the student went through to answer the question is displayed.
In reply to Tim Hunt

Re: What are all the bits of a Moodle question

by Pierre Pichet -
I was just posting this smile ...

I understand also that this will be included in 2.0 and or 2.1.
The roadmap planning document is not clear about the time left before 2.0 beta release.
What is your best estimate of 2,0 release date and this quiz redrawing project?

Pierre
In reply to Pierre Pichet

Re: What are all the bits of a Moodle question

by Tim Hunt -
Piksa bilong Core developers Piksa bilong Documentation writers Piksa bilong Particularly helpful Moodlers Piksa bilong Peer reviewers Piksa bilong Plugin developers
I refuse to try to guess when Moodle 2.0 beta release will be, nor when the actual release will follow that.

Between now and Christmas I think I have 32 working days. 4 Days at the develoers' hackfest in the Czech Republic. 7 or 9 days other features to do for the OU, and 20 days to work on this rewrite.

I am hoping that that is enough time to get the new system working for both quiz attempts and question preview, for almost all question types (I may have to leave tricky ones like calcuated, multianswer and randomsamatch for later.) However, it will probably not include updating existing quiz attempts in the database, or backup/restore (particularly restoring old 1.9 attempts into the new code).

After Christmas, I should get more time to finish this off before March (which is a key OU date). Nearer the time I will have a better idea how much work is left.

I think the probability this gets into Moodle 2.0 is somewhere between 0 and 1, but not too near either extreme. I would rather get this right, that get it finished in a hurry. (However there might be a temptation to rush something almost-complete in before 2.0 beta and finish it off during the beta testing period. Don't tell Martin I said that wink)
In reply to Tim Hunt

Re: What are all the bits of a Moodle question

by Pierre Pichet -
"there might be a temptation to rush something almost-complete in before 2.0 beta"
You are not the only one to think like this wink.


"tricky ones like calculated, multianswer and randomsamatch for later."

Perhaps you should add numerical which is more tricky than it was, with the new unit display and grading.

However, once you have set up the code flow for multitype question types, I could begin work on calculated and cloze.

Pierre