Moodle

From Gustav Delius (gwd2 at york.ac.uk) Tuesday, 17 May 2005, 03:15 AM:

Wouldn't it be better to just ask the teacher what length of answer field he wants when he sets up the question? Maybe the teacher does not want the answer field to correspond the the length of the correct answer.

From (miksik at mrakoplas.phil.muni.cz) Tuesday, 17 May 2005, 01:27 PM:

Setting field lengths individually for hundreds of questions could be quite tedious; and it seems unncecesarry to me: if the teacher should have a choice, maybe this could rather be an option on the cloze setup page: adaptive/fixed-length fields.

I think we can count on teachers wanting to have the field long enough so that students can see their whole answer filled in. Maybe I could post this into Using Moodle to discuss it with others?

From Gustav Delius (gwd2 at york.ac.uk) Tuesday, 17 May 2005, 01:52 PM:

How about giving the teacher the option to either choose a length OR have it determined from the answer. I am thinking of situations where the answer is very short but the teacher does not want to give this information away.

In any case the length of the answer field should be determined at authoring time. I.e., your code for calculating the length of the answer field should be moved into save_question(). Recalculating it each time the question is presented to a student is too inefficient.

This option should not be specific to cloze questions but apply to shortanswer, numerical, calculated, ..

From (miksik at mrakoplas.phil.muni.cz) Tuesday, 17 May 2005, 02:47 PM:

I would be happy with this being specific to cloze qs as with all other question types what would usually do would be fixed length: if it's long enough, it solves both the visibility of the whole answer filled in AND the information about the length of the answer not being given away.

The case is different with cloze qs where you need to embed the form fields into the flow of the text - it's here where too long fixed fields could degrade readability and too short fixed fields could impair students' control of their own answering.

What I have in mind is trying to keep things simple where it is possible, i.e. not adding new options if the current solution suits the needs of most users.

> In any case the length of the answer field should be determined at authoring time. [...]

Yes, if there is a db field for it, it would be much more efficient.

From Gustav Delius (gwd2 at york.ac.uk) Tuesday, 17 May 2005, 02:55 PM:

We could add such fields to the database. It should not be a field to the quiz_multianswers table but to both the quiz_numerical and the quiz_shortanswer tables. I agree with you that having variable length fields is much less important for these question types by themselves, but because a cloze question can contain several numerical or shortanswer questions as subquestions it would be easier to store the length information for each of these in the table of the corresponding question type rather than in the quiz_multinaswers table.

From (miksik at mrakoplas.phil.muni.cz) Tuesday, 17 May 2005, 03:56 PM:

OK, so the information about field length would be stored with all shortanswer and numerical questions conditionally?

a) If they are used by themselves the db field would be prefilled with a fixed value.

b) If they are used in a cloze question, the length would be calculated from the answer - provided the teacher opts for this during the cloze question setup.

Do I understand you right, Gustav?

(I'm not a programmer so I don't feel competent to comment on this really but) to me, storing the length information in the quiz_multianswers table would seem convenient if this information would not be used and needed elsewhere. An example:

id question sequence length

1 14 15,16,17,18,19 36,12,0,0,60

The zero values being filled in automatically for other then numerical/shortanswer questions.

BTW, looking at the Moodle 1.5 quiz_questions database table I can see there is a field named 'length' but I'm uncertain about its purpose.

I think this is really important (and simple) issue, as in secure mode students even can't see their answer if it's bigger than field.

I suppose, first (and very big) step to resolve this problem can be just option for the teacher to select field length according to the right answer. It easy to implement and doesn't hurt anyone, but does a lot of good for many people.

The cloze syntax has no provision to indicate the answer length.
The best solution is to keep the actual default, check the actual length.
If actual length > default adjust the legth to the actual + random value (say 2-6), so there is no clue to the student.
I will test and come back tomorrow so I assign this to me

Something like
foreach ($answers as $answer) {
if (strlen($answer->answer) > $lmax ){ $lmax = strlen($answer->answer); }
}
if (strlen($response)> $lmax ){ $lmax = strlen($response); }
if ($lmax > 12 ) { $lmax = $lmax + rand(0,6); }else { $lmax = 12 ; }

echo "lamx".$lmax." <input $style $readonly $popup name=\"$inputname\"
type=\"text\" value=\"".s($response, true)."\" size=\"".$lmax."\" /> ";

will adjust either for the answertext max length of any answers even bad ones or the student response with a 12 minimum value.
using $correctanswer will adjust on the correct answer length
$lmax = 12 ;
foreach ($correctanswers as $answer) {
if (strlen($answer) > $lmax ){ $lmax = strlen($answer); }
}

which one is the best I don't know...

The actual length (if > 12) will vary from one attempt to the other because of the rand() but I think that the only effect will be that the student won't rely on the actual length as the rigth one...

It's very good, except 12 symbol limitation.

I know complaints some people from Language department. They want to use close question with short answer field not only for words, but for commas and other syntactical elements, so they really want to have very short fields in some cases (for example comma or not).

I think initial value for $lmax is 2. As for random, it can be something like 0,$lmax/15, then it add 0-15% of correct answer length, which is much better than 0-6 symbols in all cases.

Also, I think that $lmax+/-rand() is a good value for attempt of the quiz. During viewing of finished attempt optimal field length is strlen($response)+1.

Anyway, it's very good to have this old problem fixed now. Thank's for the attention to it!!!

Thanks for your comments,
Giving a sufficient length to write the response on the attempt and to display the response after is solving a bug, so it should be done and merge down to 1.6.
Effectively having strlen($response)+1 is better than just strlen($response).

I understand your need to a shorter field but I consider that this is much as an improvement.

This could be applied to 1.9 as an improvement ( with the necessary docs modifications )
but not to older versions because it could change the actual question display without any warning.

I back Oleg's comment about the request from language departments to have the short answer fields very short, sometimes. This issue was originally filed as a New feature request. I don't think a slightly larger change would have a negative impact on displaying questions in older versions (1.6). We have used our modification since 1.5 principally unaltered (though improved on the basis of users' feedback). What we use now for setting the length of the answer fields is something like this:

$size = strlen(trim($textofrightanswer));
$size > 60 ? $size = 60 : $size = $size;
if ($size < 2) { $styleinfo = 'style="width: 1.1em;"'; }
if ($size == 2) { $styleinfo = 'style="width: 1.9em;"'; }
if ($size == 3) { $styleinfo = 'style="width: 2.3em;"'; }
if ($size == 4) { $styleinfo = 'style="width: 2.8em;"'; }
if ($size>4) { $styleinfo = "size=\"$size\""; }

You set the length following the $texttofrightanswer to which however I prefer adding some random.
how do you to obtain the $textofrightanswer ?
Limiting to 60 is a good thing.
I don't know the HTML standards sufficiently to conclude if your width settings ( em) for small size should be defined as you do.

Anyway, I am waiting for Tim comments before CVS any changes.

Adding the random part is a nice feature. We did it another way. We go through all the answers (not only the correct ones, sorry for misleading you) and use the length of the longest answer found. In this way the random part is supplied by the teachers entering the right answers and the distractors of varying, but similar, length. The code runs like this:

$size = 0;
foreach ($answers as $kk => $xshrtanswrid) {
if ($xanswer = $answers[$kk]->answer) { $xsize = strlen(trim($xanswer)); $xsize > $size ? $size = $xsize : $size = $size; }
}

The CSS style definitions were worked out empirically, I don't know how well (or if) they comply with HTML/CSS standards.

Your suggestion are quite similar to my first one
foreach ($answers as $answer) {
if (strlen($answer->answer) > $lmax ){ $lmax = strlen($answer->answer); }
}
if (strlen($response)> $lmax ){ $lmax = strlen($response); }
I will try to integrate all those suggestions so that the solution works for new questions and old ones without to much surprise for the user if his moodle site update to a new stable? version.
This improvement however does not change anything on the grading process so it can be merged down without any new bug generation...

Need Tim advice before CVS anything...

I have been following this bug, but not commenting because you were having a good discussion that I did not think I could add much to.

The only thing I don't really like is this comment http://tracker.moodle.org/browse/MDL-3274?focusedCommentId=41447#action_41447. Presumably those sizes are chosen to make the display look just right on one particular browser with one particular default font. Whatever we do has to look reasonably good in Firefox, IE and Safari.

I don't see any problem with a minor fix like this going onto a stable branch. It can only make things look better.

As regards the http://tracker.moodle.org/browse/MDL-3274?focusedCommentId=41447#action_41447 comment, we always test all CSS modifications for Firefox and IE (and Opera, sometimes). It's true we have not done extensive tests for various fonts (we used White formal theme at the time of making the changes).
The presented code is meant just as a suggestion for further development, or discarding.

The coding with em does not give sufficient space in Mac X Safari.

Simple size coding as proposed initially solves the problem.
Proceeding to furtther testing before CVS.
The actual code tested is
$size = 1 ;
foreach ($answers as $answer) {
if (strlen(trim($answer->answer)) > $size ){ $size = strlen(trim($answer->answer)); }
}
if (strlen(trim($response))> $size ){ $size = strlen(trim($response))+1; }
$size = $size + rand(0,$size*0.15);
$size > 60 ? $size = 60 : $size = $size;

From further testing it seems that explorer even when size = 1 gives you a larger display (at least 2).
However Safari is consistent and gives you the exact number...
Is there a moodle HTML specialist to set this?

I would not worry about it if the box is just a bit too big. If it was too small, then it would be a problem, because it would prevent students from seeing the answer they are typing.

And anyway, we have said it is not a bad thing if the size of the text box is slightly different from the size of the answer.

On http://tracker.moodle.org/browse/MDL-3274?focusedCommentId=41444#action_41444
We keep upgrading Moodle, so it's no problem to make improvment in 1.9. Maybe there is a need to create a special issue for this improvment ?

My proposal is to use the version that do not use the em width limits as the official one but to include
the em coding between /* */ so that administrator who wants to use, at their risk, the em will uncommented the necessary lines.
They even could try other em coefficients.
Something like
$size = 1 ;
foreach ($answers as $answer) {
if (strlen(trim($answer->answer)) > $size ){ $size = strlen(trim($answer->answer)); }
}
if (strlen(trim($response))> $size ){ $size = strlen(trim($response))+1; }
$size = $size + rand(0,$size*0.15);
$size > 60 ? $size = 60 : $size = $size;
$styleinfo = "size=\"$size\"";

/* uncomment the following lines if you want to limit size for small size

• • • • see MDL-3274
      • results could vary with browsers
        */
        /*
        if ($size < 2) { $styleinfo = 'style="width: 1.1em;"'; }
        if ($size == 2) { $styleinfo = 'style="width: 1.9em;"'; }
        if ($size == 3) { $styleinfo = 'style="width: 2.3em;"'; }
        if ($size == 4) { $styleinfo = 'style="width: 2.8em;"'; }
        */

The modifications has been CVS to HEAD, will modify the help and docs and then merge to other versions

Further tests show that even if the size parameter is the good, the browsers do not interpet this size equally.
The size is almost rigth for aaa but insufficinet for WWW.
The final results is that the input HTML element more or less reflect the answer size. In fact more for small lengths and less for larger.
But the change should be done as it reflects more correctly if not exactly (and this is good) the expected response.

CVS to HEAD and merged to 1.9 , will cVS to older versions soon

Pierre,
As you may know I have to produce a "special" version of question/type/multianswer/questiontype.php for people who use my REGEXP plugin question type to enable them to use it as a subquestion of the Cloze question. I produce this special version for all versions of moodle, starting with 1.8. So that I am kept updated of any change, would you please remember to systematically put me on the watch list whenever you enter a new bug in the tracker concerning question/type/multianswer/questiontype.php.
Thanks,
Joseph
PS.- Should my REGEXP question type make it to the regular distribution of moodle some day, then things would be much easier.

Sorry, I did not know that you have to produce a special version but I do think that this is related to your contrib project.
Take note that this just a little part of the recent changes I have done on multianswer.
There is also a new way to delete unused subquestions (MDL-12063) and the remodeling of the editor so that the text can be analysed in the Moodle editor(MDL-12255).
This has been cvs to 1,9 yesterday and will be to 1.8 and 1.7 in the following days.

For your regexp, just expect that Tim will be able to put it on the top of his to-do list.

On the long term , the solution will be the newmultianswer plug-able project that I have developped ( I will continue in the next months) or something of this kind.

Pierre, it seems you forget to set "Fix versions" field for this issue.

Thanks for your remark.
I fix it for 1.9 and working on 1.8.
And with your help, I am learning more about the various parameters of the tracker...

Pierre,
I'm a teacher interested in this variable length text box feature for embedded short answer questions. I'm currently using 1.8.4 and trying to decide whether I can wait for you to roll this into 1.8x (and then wait for the update to become available), or bite the bullet and install 1.9 now. Else, if it simply means modifying the appropriate config file, perhaps you could post the code and I can update this file manually. What do you suggest?
Thanks,
Mike Smith
(impatient course developer, addicted to embedded cloze question type)

First 1.9 is becoming more and more stable and there is even a prize contest to resolve the maximum f bugs in this versions.
The older like 1.8 will benefit as much as possible from this work.
We are polishing 1.9 before going to 2.0 .
So this is up to you but not just because of this bug...
Just wait at most a week.
University professors are often implied in a lot of other projects than this one but eventually they can do what they have planned...
Pierre

Thanks Pierre,
Much appreciated. On your advice I'm now working with Moodle 1.9 and it seems stable enough for me as well as having some other useful new features. The text box size is adapting fine but it seems to have a maximum size of around 54 characters. Is that right? Is it a hard-coded set limit? Can I increase it a bit if I want?
Mike