New 'choice' module more flexible than 'multichoice' that uses QuizQuestion interface

I may do this. I guess i need to consider #476382: Multiple choice with 4 choices correct, only one can be chosen as a part of refactoring multichoice module.

Thanks for linking to #476382. I think mbutcher's suggestion to rewrite multichoice altogether may be the better course of action than just refactoring it. We could think of this issue as "make new multichoice module based on QuizQuestion"

This could be an opportunity to make a very flexible choiceInteraction question type, per the QTI spec,
http://www.imsglobal.org/question/qtiv2p1pd2/imsqti_implv2p1pd2.html#sec...

just consolidating the other feature requests relevant to this

1. #331438: Quiz with question where a or b or c are ok, but points depending on what they score
2. #322405: Quiz Questions Support
3. #506160: Scoring of different question types
4. #509686: Expandable answer list in multichoice editing
5. #476382: Multiple choice with 4 choices correct, only one can be chosen

I've discussed this with turadg and sivaji. I'll refactor/rewrite multichoice when I'm finished with scale.

After a long IRC chat, we've come up with some ambitious ideas. Lots of them will have to wait a while, but the general direction is to align with QTI.

The first step in that is terminology. The module will be called "choice" to match QTI's "choiceInteraction", http://www.imsglobal.org/question/qtiv2p1pd2/imsqti_implv2p1pd2.html#sec...

A key difference between Drupal Quiz and QTI is that QTI (2.x) allows multiple interactions within an item. That is, an itemBody can contain, e.g. a choiceInteraction and a sliderInteraction. It can also have multiple response variables (the effect of the interaction), and separate outcome variables (e.g. score). A responseProcessing script specifies the outcome value for the response values.

In Drupal Quiz 4.x, we'll stick with the one interaction per question model we have now. In QTI parlance that means each item has one interaction that is at the end of the item body, one response variable, and one outcome variable.

falcon will be adding a nice feature (requested within http://drupal.org/node/506160) to allow different scores for each choice, approximating some of the complex response processing that QTI supports. Moodle and WebCT formats also support this.

Thanks falcon!

After a long IRC chat, we've come up with some ambitious ideas. Lots of them will have to wait a while, but the general direction is to align with QTI.

The first step in that is terminology. The module will be called "choice" to match QTI's "choiceInteraction", http://www.imsglobal.org/question/qtiv2p1pd2/imsqti_implv2p1pd2.html#sec...

A key difference between Drupal Quiz and QTI is that QTI (2.x) allows multiple interactions within an item. That is, an itemBody can contain, e.g. a choiceInteraction and a sliderInteraction. It can also have multiple response variables (the effect of the interaction), and separate outcome variables (e.g. score). A responseProcessing script specifies the outcome value for the response values.

In Drupal Quiz 4.x, we'll stick with the one interaction per question model we have now. In QTI parlance that means each item has one interaction that is at the end of the item body, one response variable, and one outcome variable.

falcon will be adding a nice feature (requested within http://drupal.org/node/506160) to allow different scores for each choice, approximating some of the complex response processing that QTI supports. Moodle and WebCT formats also support this.

Thanks falcon!

The module is named choice and can be found in 4.x-dev. I'm still working on it and any feedback would be appreciated.

Looking good, falcon.

One critical need is to observe the "view quiz question solutions" permission, described in http://drupal.org/node/512674 . The older "multichoice" module code demonstrates how.

A more general feedback is that the UI gets very busy with the WYSIWIG editor and even more so when the Advanced fieldset is opened. While the question body may have complicated HTML that needs many buttons in the editor, the answers rarely will, I expect. I wonder if there's a way we can pare down the buttons for the answer fields.

Lastly, it would be nice if users could add and remove alternatives dynamically.

Thanks for the feedback.

1. "view quiz question solution" permission

I've tried to allow for the "view quiz question solution" permission now. My changes is shown in the attached patch, and is also commited to 4.x-dev.

2. creation form and wysiwyg

I agree. The form is probably too big without wysiwyg, and when wysiwyg is attached(especially if many buttons are enabled) the form might scare away many users. I haven't found any good solutions for this yet. Possibilities I can come up with to help this are:

2.1 Remove buttons from wysiwyg
As you suggest. It was possible to do this with tinyMCE module in D5 with templates. I don't know if it is possible with the wysiwyg module.

2.2 Place the advanced options somewhere else
Maybe we could make the advanced options open in lightbox or in seperate tabs or something.

2.3 Admin can remove wysiwyg from alternatives
We can let the admin completely remove the wysiwyg from the alternatives by clicking a checkbox or something in the choice admin page.

2.4 Wysisyg only active in the field beeing edited
This would probably be a part of the ideal solution, but I don't think it is possible at the moment.

Any real good solution on this matter would be appreciated! As I see it a good soulion at the moment would be to add an admin setting to allow wysiwyg on alternatives or not. If it isn't allowed we might show the creation form in a table like the old multichoice module does.

Advanced and experienced drupal users might want to use pictures and formatting in their answers and feedback. They could use the wysiwyg enabled version of the creation form. Less advanced users will be scared away by all the options and should be presented with a simpler form without wysiwyg.

Any thoughts?

3. Add and remove alternatives dynamically

Beeing able to add alternatives dynamically is already on my to-do list. I haven't considered beeing able to remove them dynamically. Beeing able to add is most important? (You can just leave alternatives empty to remove them)

Attachment	Size
quiz-508744.patch	1.42 KB

for (2), I think (2.4) is the best solution, but I don't know how to do it.

One thing that would help unclutter the choices selection is not providing an Input Format choice for each separate field. Currently, there is an input format for each alternative answer and its feedback. Thus there are alternativecount * 2 selection widgets to choose an input format. I can agree there's a good use case for having a different input format for the question body and the answers, but do we need one for each individual answer?

How about we have one input format for the answers all together? This can be a property of the question itself. Then we can drop the format columns from the answers table.

As for (3), I don't think it's obvious that leaving a field empty would remove it. The user may expect an empty answer to appear. So better to have a dynamic remove feature too.

Also, I wrote this earlier in IRC but since I'm typing here to: I suggest changing the ->alternatives array to be numerically indexed. Currently it has keys ['multi'] and ["alternative$i"] for each alternative. Instead we can have node->multiple_selection, node->answers_format, and node->alternatives. The alternatives array would be numerically indexed from 0, allowing node->alternatives[] queue pushing (which is used in the import code).

Working in the Moodle importer, I've come across this question data:

questiontext Which pair(s) of ions will form a compound of formula MX?

defaultgrade 1

answer Array [4]
1 ammonium and sulfide
2 calcium and carbonate
3 lead and acetate
4 magnesium and oxide

fraction Array [4]
1 -0.2
2 0.5
3 -0.2
4 0.5

So they got 1 point if they answer 2,4 (the sum of those points) and lose points for answering 1 or 3. Is that how the Choice module works? Does it add and subtract points for chosen?

Another suggestion :)

Make the answer text be the for the radio button (or checkbox) so it can be clicked on instead, a much larger target.

Regarding #11:

turadg and I have spoken about it on IRC. For other readers here is what was said:

The score thing works the way you want it to
but there are two scores, score_if_chosen and score_if_not_chosen
if negative scores are used for wrong alternatives(like they are in your case) let score_if_not_chosen be 0 for all alternatives
(and set score_if_chosen to the values in your example)

Remember: If multiple answers are allowed there has to be negative points for chosing wrong answers, or positive points for not chosing them. If not the student can allways choose all answers and get maximum scores.

If I recall correctly it is impossible to create a question that doesn't punish wrong answers one way or the other. The system will correct these automatically or show error message.

Regarding #12:
Thanks for the tip! It has been added to my to-do list.

Regarding #10:
Thanks for the suggestions. I've added everything to my to-do list except the wysiwyg thing. I'm considering to add it to wysiwyg.module issue list :) Also the dynamic remove feature isn't high priority. I'll rather add a description below the textarea saying something like "Empty alternatives are not added to the question".

I would love a common input format for all the textareas, but I haven't found a good way to remove the filter fieldsets without also removing the entire wysiwyg editor. I'm also afraid that it won't be possible to do it, but I'll once again add an issue on the wysiwyg todo list.

(I do think that using a jQuery hide() function can remove the filter format fieldset as you suggested turadg, but that will make the filter format uneditable because I don't think it is possible for me to tell all the wysiwyg to listen to a master filter format selector. But if a user only has one filter format available all filter format text is removed in the original choice design.)

Maybe it is possible to hide all format selectors, and make one edit selector change all the others when the selector itself is changed? I have litle jQuery experience, but I'll give it a try!

re #15: yes, I think that's the best way. just hide all but the first one and set a .change() handler on it to update the state of the hidden ones. jQuery makes it remarkably easy, but if you run into any trouble I'm sure #drupal-quiz will solve it.

falcon, I just committed some improvements to how questions are presented outside a quiz-taking context. The correct answer is now colored instead of appending text and the input fields are disabled.

To set up the style of the background-color, I made choice/theme/choice.css, which I figure can grow and allow users to theme override using just CSS.

re #17: Looks good!

(I think I'll move the drupal_add_css to the template file)

Cool. I just updated. When I ran update.php, I got these errors:

# warning: Missing argument 5 for db_change_column(), called in /Applications/MAMP/htdocs/drupal-6.13/sites/all/modules/quiz/question_types/choice/choice.install on line 165 and defined in /Applications/MAMP/htdocs/drupal-6.13/update.php on line 107.
# user warning: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'TO multi_old' at line 1 query: ALTER TABLE quiz_choice_properties RENAME multi TO multi_old in /Applications/MAMP/htdocs/drupal-6.13/update.php on line 125.
# user warning: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '' at line 1 query: ALTER TABLE quiz_choice_properties ADD choice_multi in /Applications/MAMP/htdocs/drupal-6.13/update.php on line 126.

I tried adding the 5th column ('int') but I still got the RENAME errors. I hope you have better luck. ;)

http://drupal.org/node/429786#comment-1873726

Install file uses db_change_field now. I was suppose to test the update hook, but I probably forgot and did a reinstall with devel instead. Sorry guys.

Now you can click anywhere on the alternative to select it(commited to 4.x-dev)

re #22, that's a nice feature. It's implemented with jQuery now, which I found a little difficult to follow. The HTML tag is made just for this purpose. Did you try that way too? I think the code would be easier to understand using that, if possible.

Also with regards to readability, there are many loops like this:

for ($i = 0; is_array($this->node->alternatives[$i]); $i++) {
$short = &$this->node->alternatives[$i];
// logic not needing an index
}

that would be easier to read as:

foreach ($this->node->alternatives as $short) {
if (empty($short)) continue;
// logic not needing an index
}

and for logic needing an index:

foreach ($this->node->alternatives as $i => $short) {
if (empty($short)) continue;
// logic using index $i
}

It also changes the behavior slightly, but I believe for the better. It omits any empty alternatives, rather than stopping at the first one. E.g. if the 3rd answer is empty but the 4th is included, the earlier code would lose the 4th but this will not.

re: #23
Thanks for the feedback turadg!

I will try using the label tag!

I agree that using foreach initially is easier to read. The module uses a normal for loop now of historic reasons. The alternatives array earlier contained elements that wasn't alternatives, but the alternatives had numerical indexes from 0-n.

Regarding this: "It omits any empty alternatives, rather than stopping at the first one. E.g. if the 3rd answer is empty but the 4th is included, the earlier code would lose the 4th but this will not." - If an answer is left empty is_array($this->node->alternatives[$i]) will still return true, and the loop will continue. It will not lose the 4th.

I will do a review of the choice code when all functionality is in place, and I will consider changing how the loop is written then. It will probably be foreach, also because I think I will have the indexes in the array be ids from the database instead of a serial index.

The label tag adds css formatting to the content inside it. Obviously we can add a class to the label tag trying to clear all css formatting, but I don't know any clean way to do it. Because of this I suggest sticking with the js. When I review the choice code I will add comments making it more readable.

Shoot, I forgot about making the text bold. Can you make the jQuery highlighting work in the new AJAX quiz-taking interface?

It should be working already. I fixed that issue last week.

The problem:
When a question is loaded using ajax drupal_add_js (and drupal_add_css) is unable to attach a file to the header.

The temporary solution for choice:
Added the js inline from the tpl file in an ugly way. Just wanted to make it work for now. Will make a prettier solution prior to the release.

A standard solution:
Are there any best practices for this? We surely aren't the first to have this problem. Possible solutions:
- Ajax quiz triggers some hooks in the question type modules.
- The question types implements an already existing hook where it adds css and js.
- We simply always add the js and css inline, using drupal_add_...