As far as I can see, they serve no useful purpose.
Some people don't want them, and there is no way to get rid of them.
For people who really want them, they can enter them manually as part of the answer.
Hmm, this is a very interesting concept! But it makes me think of a question. If you entered them as part of the answer and selected "shuffle answers", wouldn't that cause a problem?
Sometimes I print the tests (my penalty for students who don't get them done on-line in the required time, so I don't have to keep the quiz open). In this case, I might like the a. b. c. I am not sure if it makes a lot of difference, though!
Maybe this is a case of convention more than logic!
What would your faculty say? I would be very interested in the response. I will ask mine and post back with a summary of their responses! This is something that might turn out to be bigger than you first think. . . fascinating idea!
atw
Sometimes I print the tests (my penalty for students who don't get them done on-line in the required time, so I don't have to keep the quiz open). In this case, I might like the a. b. c. I am not sure if it makes a lot of difference, though!
Maybe this is a case of convention more than logic!
What would your faculty say? I would be very interested in the response. I will ask mine and post back with a summary of their responses! This is something that might turn out to be bigger than you first think. . . fascinating idea!atw
Summary for the faculty who responded to my query in the first 5 minutes!
More later . . .
- I frequently use questions with answer/options such as: Both A & B, A, B, & C, etc. I need to see those letters!
- I haven't used the quiz feature, but the only use I can think of for lettering the answer choices is if you later published an answer key. I have no problem with making them optional/manual, though, rather than built-in.
- I think we should have the option of abc or none. If I had to choose, I’d choose abc automaticity.
- I’m fine with no a,b,c’s. Not sure why we use them either.
- I think the a, b, c, d, (e) comes from standardized testing that used SCANTRON-type “fill in the zone with the No. 2 pencil” answer sheets. The letter became a transformation (representative) of the selected answer. Otherwise, there is no need to associate the letter with the selected answer.
- On Moodle – a. b. & c. probably do not matter…except distinguishing quickly between answers when students ask questions.
- On regular exams graded on scantron sheets then changing a. b. & c. would really matter because it would require an industrial paradigm shift.
More later . . .
A few thoughts and two proposals.
- Numbering the choices in a MCQ question is done differently in different languages: letters (a. b. c.) are the preferred option in English, numbers (1. 2. 3.) are used in French. At the moment, Moodle imposes the "anglo-saxon" model.
- Numbering the choices can serve a purpose in the case where answers are set to "non shuffled" in order to enable such choices as:
- a. blabla
- b. blibli
- c. blublu
- d. a and b
- e. b and c
- As mentioned by A. T. Wyatt, some numbering system is needed if the quiz is to be printed.
- On the other hand, using a. b. c. etc. letters for numbering the choices can pose a problem when the actual wording of the choices is made of letters A, b, C, etc. (this question has been posted several times on this forum).
- If people agree that we do not really need the a. b. c. numbering system, we might replace it with either (a) a supplementary option or (b) a theme CSS formatting.
- a. b. c. (this might be the default setting)
- 1. 2. 3.
- bullet
- none
CSS formatting: simply add a .question.mcq_line_style class in the code of the MCQ question and a corresponding class in standard theme, so that theme creators could decide on their favorite styling, from the list of available letters, numerals, bullets, etc. Again I suggest that in standard theme the default for this class would be a. b. c.
Joseph
Joseph - I am all for giving the users choices. It seems reasonable to me to offer a multiple choice question prefix type as your describe as being either letter based, numerical, roman, whatever or as some would prefer none. I think many students are used to paper based tests and it is good to have the a, b, c, option. For non-shuffling of answers within a question as Tim notes the user can put that in but it is nicer (IMO) if Moodle handles that. Then as a teacher if I choose to change it from an alphabetical prefix to none I have that choice. It would not seem to me that hard to program and to make it an option. My biggest concern would be to just take it out because then teachers who in previous versions who have relied on it no longer have it and it would seem (at least from a user's perspective) to be a loss of functionality. By default it should remain at the alphabetical and users could then remove them from questions that they do not want them for. Peace - Anthony
>>Hmm, this is a very interesting concept! But it makes me think of a question. If you entered them as part of the answer and selected "shuffle answers", wouldn't that cause a problem?
We do mass testing with students sitting next to each other doing the same test. Shuffling answers is wonderful to handle 99% of the temptation to copy. We also keep a printed version of the online test handy in case the system breaks down on Test Day (this has happened). So yes, a. b. c. or some other numbering system is probably good, though I may opt for "no auto-lettering" in cases. This is a good question and I will check it out with our other teachers.
The most ideal solution is to have an advanced option where the quiz maker can set the numbering system:
We do mass testing with students sitting next to each other doing the same test. Shuffling answers is wonderful to handle 99% of the temptation to copy. We also keep a printed version of the online test handy in case the system breaks down on Test Day (this has happened). So yes, a. b. c. or some other numbering system is probably good, though I may opt for "no auto-lettering" in cases. This is a good question and I will check it out with our other teachers.
The most ideal solution is to have an advanced option where the quiz maker can set the numbering system:
- a. b. c.
- 1. 2. 3.
- no numbering
- custom numbering system...
Hello Tim,
I would prefer that the a, b, c,... labeling for multiple choice questions goes away since it creates confusion for my students when I use algebraic expressions (which also include letters) as answer options. I am using Moodle 1.6. Do you have, and could you give me instructions on how to get the letter labeling to disappear ?
Thanks in advance.
Cristina
It is an easy change to make. In question/type/multichoice/questiontype.php. In the print_question_formulation_and_controls function. Delete the bit I have crossed out below.
// Print the answer text
$a->text = format_text("$qnumchar. $answer->answer", FORMAT_MOODLE, $formatoptions, $cmoptions->course);The hard bit is trying to get consensus about whether that is a good or bad change.
Greetings, Tim!
I have heard back from 16 instructors. The following table summarizes the results. Each faculty member could and did express multiple points, so that is why you see the larger numbers here!
One math professor said that the letters drove her students crazy because the same letters also referred to variables in the algebra problems. So an answer could be a. B, meaning that the first choice (a) referred to the variable B. The presentation was confusing! (so this agrees with Cristina's post, above)
So there you have it. I think many of my faculty use paper versions of the tests, and they are concerned with a solution that works for the screen and for paper. Many like the idea of an option showing no separator, a letter separator, a number separator, or a bullet separator!
atw
I have heard back from 16 instructors. The following table summarizes the results. Each faculty member could and did express multiple points, so that is why you see the larger numbers here!
| Comment |
Number expressing |
| I use tests with A, A and B, B and C, so I need the letters |
3 |
| I do not care either way; screen tests do not require letters |
4 |
| I would like to have the letters to use for subsequent reference when discussing or reviewing a test with students (implies a paper copy, but not necessarily) |
2 |
| I want letters or bullets because it helps students separate the different choices for the distractors |
3 |
| We should have letters because they are familiar--don't add to student/faculty anxiety! |
3 |
| I need the letters because I also use paper versions of the tests. |
7 |
| I would like to have an option of bullets, letters, numbers, or none |
5 |
One math professor said that the letters drove her students crazy because the same letters also referred to variables in the algebra problems. So an answer could be a. B, meaning that the first choice (a) referred to the variable B. The presentation was confusing! (so this agrees with Cristina's post, above)
So there you have it. I think many of my faculty use paper versions of the tests, and they are concerned with a solution that works for the screen and for paper. Many like the idea of an option showing no separator, a letter separator, a number separator, or a bullet separator!
atw
Tim > I really need to get a life.
How about a second life? 
Sincere thanks & congrats for your work on Moodle dev.
Joseph
Results of testing in 1.9 today:
1- Create new MCQ question and select the new Number the choices? option
| abc |
abc |
| ABC |
abc |
| 123 |
123 |
| none |
none |
All work except for ABC which reverts to abc (lowercase).
Export / Import newly created QCM questions in Moodle XML format does not work. I expect the various import/export formats (at least the Moocle XML format) will have to be modified to take the new option into account.
Thanks,
Joseph
Thanks for the testing. I had fogotten about backup/restore and import export. I have fixed that now but not checked it in.
The problem with abc/ABC is that internally I was using identifiers abc, ABC, 123, none to distinguish the choices. HTML does not like ids that differ only in upper/lower case. So I need to change ABC to ABCD, or something, but the wonderful new database table updating library has a bug. Hopefully Eloy can fix that, then I can fix this question type.
The problem with abc/ABC is that internally I was using identifiers abc, ABC, 123, none to distinguish the choices. HTML does not like ids that differ only in upper/lower case. So I need to change ABC to ABCD, or something, but the wonderful new database table updating library has a bug. Hopefully Eloy can fix that, then I can fix this question type.
Hi Don,
I expect you would like to have a facility similar to what we get in web-authoring packages when creating styles (see attached, from Macromedia Dreamweaver™). If Tim could find a way to put this into his MCQ choices numbering dropdown list, then everyone would be satisfied (or would they?
) I'm afraid Tim opened a bigger can of worms than he expected.
For more info on list-style-type in CSS 2 see I18N Tests: list-style-type.
Joseph
Hi Tim,
I have examined your get_numbering_styles and number_in_style methods. They work fine for standard, ascii characters, but do not allow the use of Japanese, roman, etc. methods of numbering.
1- Based on your work I am therefore proposing a new method, which entirely relies on the CSS2 list-style-type types. As show on attached screen shot, this allows for the entire range of CSS2 list-style-type types available, except for the bullets, which we are agreed are useless in this context. And of course it includes Japanese styles, etc.
Another advantage of my method is that numbering styles only have to be declared upon installation, in the answernumbering column/field of the question_multichoice table. They are then retrieved from that table for use in this function
function get_numbering_styles() {
$result=mysql_query("SHOW COLUMNS FROM mdl_question_multichoice LIKE 'answernumbering'");
$row=mysql_fetch_row($result);
preg_match_all("/'(.*?)'/", $row[1], $matches);
$arryEnum= $matches[1];
return $arryEnum;
}
2- I am also suggesting using the standard list-style-type terminology, instead of translating it. In the lang. file, this means using
$string['answernumberinglower-alpha'] = 'lower-alpha';
rather than
$string['answernumberinglower-alpha'] = 'a., b., c., ...';
This may look less user-friendly to the end-user, but they will get used to it, and it is coherent with web-authoring packages listing. The only string that might need "translating" is none -> No numbering. The other advantage is that keeping the CSS terminology in the numbering styles listing in question editing obviates the MSIE problem described below, i.e. such styles as katakana, hebrew, etc. will still be readable in the list rather than being replaced by garbage is e.g. katakana equivalent to a,b,b is used in the lang. file.
3- Display results and problems
a) All of the language-related list styles display fine in FireFox (version 2.0). In MSIE (7.0), unfortunately, very few are displayed OK (lower and upper roman); most are not (katakana, etc.) they are automatically replaced by decimal figures. One more reason for adopting FireFox!
b) The final result (as shown on attached screen shot) is OK in MSIE 7 (except for not displaying a number of language-related styles) but there is a slight alignment problem in FireFox. Because the choice text is displayed as an ordered list <ol><li>...</li></ol> located within a table cell, FireFox decides to display that list with a vertical space above and under it. I have not managed to destroy that unncessary vertical spacing, but I'll keep trying, and hope someone may suggest a solution.
As a conclusion, in keeping with Moodle's "international" vocation, I hope you will consider my efforts to making the list numbering more international, and I'm looking forward to moodlers' views.
Joseph
Oops! that was lower-roman illlustrated in my screen shot!
Attached zipped diff/patch files against Tim's most recent multichoice files. Diff files produced with WinMerge.
Joseph
Attached zipped diff/patch files against Tim's most recent multichoice files. Diff files produced with WinMerge.
Joseph
I don't like the direction you have gone with this Joseph. It is great if you know all the details of numbering styles in CSS2 and want ultimate flexiblity. But actually, most people want a few basic choices, and therefore what you have done is overcomplicated.
And I think it is a good idea for the letter option to be in the language file. So I think I will change it to offer just three options, which in English will be
a., b., c., where the parts come from the language file strings answernumberinglang1, answernumberinglang2, ... Can anyone tell me now many of these I should have. For the UK, 26 is a sensible maximum number. What is it for other alphabets?
The other two are 1., 2., 3. and no numbering.
Those are the key choices to offer people, without making it too complicated. It will still be very easy for people to add more by hacking the code.
And I think it is a good idea for the letter option to be in the language file. So I think I will change it to offer just three options, which in English will be
a., b., c., where the parts come from the language file strings answernumberinglang1, answernumberinglang2, ... Can anyone tell me now many of these I should have. For the UK, 26 is a sensible maximum number. What is it for other alphabets?
The other two are 1., 2., 3. and no numbering.
Those are the key choices to offer people, without making it too complicated. It will still be very easy for people to add more by hacking the code.
>>I don't like the direction you have gone with this Joseph. It is great if you know all the details of numbering styles in CSS2 and want ultimate flexiblity. But actually, most people want a few basic choices, and therefore what you have done is overcomplicated.
In checking with my colleagues, a Japanese test, such as an entrance test will have numerous numbering system in addition to katakana. For example, a,b,c is used frequently, as well as, 1,2,3, and 1,2,3 with circles around them. Many of these are not in standard ASCII but extended (is this called double-byte?). Therefore a single numbering system for a whole test is not always the case. Several systems will be mixed.
Now I do not know how important it is to allow multiple numbering systems according to sections of the test--but lets assume that is not urgent for now. What is important is that we make it easy to switch--and at least have the choice of roman, numbered, and another alphabet, or none. I would prefer a custom numbering field rather than translate in a language because that could eliminate roman numbers in a site/course/quiz set for Japanese. My colleagues would hate that--they want to option of roman as well as katakana. I think Joseph's proposal offers the most flexibility. If that is is too complicated then let's go with four basic choices...
In checking with my colleagues, a Japanese test, such as an entrance test will have numerous numbering system in addition to katakana. For example, a,b,c is used frequently, as well as, 1,2,3, and 1,2,3 with circles around them. Many of these are not in standard ASCII but extended (is this called double-byte?). Therefore a single numbering system for a whole test is not always the case. Several systems will be mixed.
Now I do not know how important it is to allow multiple numbering systems according to sections of the test--but lets assume that is not urgent for now. What is important is that we make it easy to switch--and at least have the choice of roman, numbered, and another alphabet, or none. I would prefer a custom numbering field rather than translate in a language because that could eliminate roman numbers in a site/course/quiz set for Japanese. My colleagues would hate that--they want to option of roman as well as katakana. I think Joseph's proposal offers the most flexibility. If that is is too complicated then let's go with four basic choices...
- roman alpha
- arabic number
- custom alpha/numeric (allowing double byte characters)
- none (as default?)
I think we should err on the side of simplicity, rather than flexibility, while making it easy for people to customise further if they need to in the code. And I think my revised code achieves that.
That only leaves the question which short list of simple options should we offer, and I think that your list of four looks good, and you give a good logical answer why those four are necessary.
This setting is made on the question, therefore, you can combine different styles in one test.
That only leaves the question which short list of simple options should we offer, and I think that your list of four looks good, and you give a good logical answer why those four are necessary.
This setting is made on the question, therefore, you can combine different styles in one test.
Hi Tim,
Further to your message I have refined my solution in order to offer - hopefully - both simplicity and flexibility.
Going the CSS list-style-type way seems to me the most reasonable (and logical) option. Since CSS2 offers a way to automatically number lists in a variety of styles (including those proper to certain languages) I would not call providing something like 26 answernumberinglang1, answernumberinglang2, etc. language strings opting for simplicity. The CSS option offers the added advantages of providing a wider choice of 'non-language' options, (a. b. c.; A. B. C.; 1. 2. 3.; 01. 02. 03.; i. ii. iii.; I. II. III.) and, in the case of Japanese, a choice of 4 numbering options. The only problem that remained in my previous solution was the vertical misalignment of radio-button, choice text and feedback message. I have now found a solution for this, as shown on attached screen shot. It was a simple matter of setting margin-top and margin-bottom to 0.
As regards simplicity for end-users, I agree that displaying the actual style rendering values (a. b. c. d.) in the drop-down list rather than their CSS names makes selection easier, as does the grouping of the most commonly used values at the top of the list. For language-related styles, however, I prefer to keep their names. This should be no problem to the (few) users who would have to use them, and who know what the names stand for. In the language files (other than English), of course, any other method of display might be adopted, including local variations of lang. files. The solution I propose is both simple (users can concentrate on the most frequent, top-listed styles) and complete.
As regards the feasibility of "hacking the code" for people who want more flexibility. First of all we must bear in mind that, although Moodle is open source, it does not necessarily follow that all moodle users are either a) able or willing to hack the code b) in a position where this is allowed. In large institutions, admins are extremely reluctant to hack the Moodle code at all... and Open source then means... closed.
In my CSS solution, there should normally be no need for hacking the multichoice code, since all foreseeable list-style types would be included... Unless there exist certain languages which rely on list numbering characters not included in the CSS2 types. Can anyone tell us? There is also the MSIE-related problem, but that's not too bad because when MSIE can't display certain list-style types, it reverts to decimal numbering. I don't know about other browsers; could people please check and report?
In your solution, hacking the code (for providing extra flexibility, adding new numbering strings, etc.) involves changes in no less than 4 different places: the answernumbering field in the question_multichoice table; the language file; function get_numbering_styles() and function number_in_style($num, $style) functions in the questiontype.php file. On the other hand, in my CSS solution, hacking the code (if new CSS styles should become available in further CSS specs or if CSS types needed to be removed or re-ordered) only the first two places (the answernumbering field in the question_multichoice table and the language file) would have to be hacked... there should be no need to hack the questiontype.php file at all.
Looking forward to your and fellow Moodlers' views on this new proposal,
ATB
Joseph
PS.- Screenshot and new, slightly modified DIFF files attached to next messages.
Joseph, I have come round to your way of thinking during the last week while I have been too busy to work on this.
I was just trying to merge your patch in, but unfortuately <li value="2"> is not XHTML Strict, and these days, all core Moodle code has to be.
It would be nice to lose the HTML table altogether, and just use an
I was just trying to merge your patch in, but unfortuately <li value="2"> is not XHTML Strict, and these days, all core Moodle code has to be.
It would be nice to lose the HTML table altogether, and just use an
- to layout the question, but I can't work out how to do that, and get the letter after the radio button, and make the feedback appear in the right place. Any thoughts?
Tim,
Thanks for your message. Too bad XTHML Strict have decided to abandon the <ol> and <li> start and value attributes, which would be quite useful in this case. And I think there are still a large number of "obsolete" tags in Moodle core code at the moment, no? Is it planned to remove them altogegher? for Moodle 1.9? or 2.0???
Em, what do you mean: " It would be nice to lose the HTML table altogether, and just use an *** to layout the question"?
I'll look into this ASAP and report here.
Joseph
There was a huge effort to make Moodle 1.8 comply with XHTML strict, and from now on, all new Moodle code should be valid XHTML strict, and any old code that isn't should be reported as a bug.
This was talked about at the developer meeting last week. If you have not seen them, there are some brief notes here: http://docs.moodle.org/en/Developer_conference_April_2007
Since the OU paid for all that accessibility work, I feel I should set a good example in this respect.
This was talked about at the developer meeting last week. If you have not seen them, there are some brief notes here: http://docs.moodle.org/en/Developer_conference_April_2007
Since the OU paid for all that accessibility work, I feel I should set a good example in this respect.