Quiz

"So I don't want to expand it much more. Therefore, I think you should wait until this work is done, and then once the code has been cleaned up, it should be easier to do your changes."

So you don't want to implement now the multianswer question types in the report analysis.
And I should wait that all the code is cleaned and ported to Moodle 2.0 so one year from now.

Should I understand that it is better to stop working on calculated question type and come back in January 2009 !!!

Pierre

"and it will be included in Moodle 2.0, which is probably about a year away."

Can I conclude that this will not be merged in 1.9, 1.8,1.7,1.6?

If this is the case, I could explore the necessary changes to modify for these versions the report analysis so that it could display the Cloze multianswer and the multianswer calculated question type in the actual format.
Something similar to the example in this discussion thread (or topic) with a more explicit display of the subquestions question text.
Even if these modifications just lived in 1.9, 1.8,1.7,1.6 they will be useful for many years to many moodle intallations.

Pierre

P.S. Technically this implies the creation of a get_subquestions() function in questiontype and some modifications to the actual code flow to retrieve these subquestions correctly. The default get_subquestions() for all the single answer question types will return "" (or false?). See MDL-11441.

That is basically right. For the whole of 2008, the OU version of Moodle will be based on the 1.9 branch, and we want to include these new reports in our next release that is being developed over the next few months, then tested, then release in July.

Of course, being nice people, we don't just want these improvements in OU moodle, we want to donate them to the community as well. But changes of this magnitude cannot go into the public 1.9 stable branch, they have to go into HEAD there.

So that is the problem we are having to solve. The 'OU guys who will be merging' is me, so I have a strong incentive to have the merge be as easy as the tools, CVS/patch/diff will allow On the other hand, I have some practice at doing this sort of thing.

You are right that the areas of the code that this affects will be very similar between HEAD and 1.9 (until your changes go in) so merging should be quite easy. The difficulty is where this work involves improving core code like tablelib.php. It is probably good enough if you just keep a note of which files outside mod/quiz/reports get changed as you do this work.

We need to ask Martin D if these changes are big enough that he wants them on a development branch off head, of if he is happy for them to go straight in to core. A development branch probably makes merging slightly easier for me, but really that decision is for Martin and should be based on other considerations.

Of course, Martin Langoff would tell us that Git is the appropriate tool for this problem, but I have never got my head round it, so it does not seem fair for me to expect you to.

Ignore the two parent posts here. I was confusing the Item Analysis Report overview mode and the separate Overview report.

I will answer anyway, to give the rationale behind this.

The analysis for a single question can get quite big. Maybe not for a multiple-choice question, but suppose you have a shortanswer question, where it has a row for each different answer that at least one student entered. If you have a quiz taken by a few hundred users, there can be tens of different answers between them.

And there are times when you just want to see the summary statistics for each question in the quiz, to be able to see at a glance whether there is one question that looks like it has a mistake in it, because the discrimination index is much lower than for the other questions. A table with one row for each quiz question is also a fair chunk of data.

Hence my thought that for online use, what you want is one screen for the summary statistics of each question in the quiz, with drill-down to the detailed analysis of each question.

But you also need a third mode, for the benefit of people who like to print things out on dead trees and stick them in a filing cabinet (), or people who want to get all the data in one excel spreadsheet. For them, you want a single document, obtained by concatenation first the summary table, and then the drill-down for each individual question. Hopefully that is not too much extra work to implement.

Please ignore the two parent posts of this post as well. Confused the item analysis graph and the summary graph.

Hi Pierre,

See the attached screenshot. The data we imported wants the answer to be "830,000.", but that string isn't included anywhere in the markup that presents to the teacher the screenshot I've attached. So the teacher is left thinking "well, that looks right to me" instead of giving the student comments such as "remember that the directions instructed you to include commas and a decimal..."

Of course, IMO it's just weird that the decimal is included in the expected answer with no significant figures after it, and while that is a content issue in some sense, Moodle should be telling the teacher what answer it was expecting so the teacher can understand why the question was automatically graded the way it was.

Regards,
Matt

I'm really new to moodle and not a programmer, so there is a lot I don't understand. I tied to look at the links to the bug tracker, etc. and hardly understand a word of it. I have two questions:

a. What's a HEAD"? I see references to making the changes there, but I can't figure out what that means.

b. Will the new stats reports include difficulty factors for each question?

I apologize if I've made a netiquette error here; the only excuse I can offer is that for someone like me, a teacher-user, some of this can be hard to follow.

tnx and regards

mark c. miller
noblesville indiana

I should give some more background about our school and how we're using Moodle; that will make quite a bit more sense out of my comments about what we need.

We have rolling enrollments, so students may be spread out over the different sections ("topics") of any course at any time. This means that assessments (we're only using Moodle's quiz module ATM) never "open" or "close", and there are technically never due dates. Students are allowed to submit new attempts (up to a limit) for each assessment at any point in the course.

In case it isn't already obvious, we're using Moodle as a tool for each student to have a very individual relationship with her teacher, and occasionally some interactions with other students in forums, chat, etc.

I just checked, and 6246 out of our 46302 questions in the DB are 'essay', so the majority of our assessments are automatically graded. However, we're expecting our teachers to provide lots of 1-on-1 feedback to students, and this takes the form of comments (and occasionally grade overrides). Unfortunately, the 9606 random-selection questions in our database cannot be commented upon (effectively), and their automatically-assigned grades cannot be overridden (effectively). I believe this is my #1 Moodle issue for our school right now.

• We need a better flow for students to naturally find themselves viewing teacher comments, just like when a paper gets handed back in a classroom.

Actually, I meant it as a general statement, since we're wanting our teachers to provide so much feedback (even on auto-graded assessments) to students. I'd like students to land in Moodle and find themselves looking at a stack of graded assessments with comments, as it were. I haven't even begun to think of an interface for this, but I think a block could handle it nicely, with a link to a report page (analogous to the grading reports page(s)) that provides links to assignments with unseen comments. This does imply that Moodle needs to keep track of which comments a student has viewed before.

Analogously, it needs to be easy for our teachers to see which submitted assessments they've reviewed (and commented on) and which they haven't. This implies that Moodle needs to track these things.

I'm planning to implement such a tracking system (perhaps sharing some code and DB tables for the student & teacher sides) and present it to the user in a block, at least to demo the idea to other devs.

• Teachers need to be able to assign grades to quizzes that haven't been submitted by the student.

I meant what I said, but I totally see why you see it as dangerous. I think this is a site-wide policy issue (and it should not be available by default), but it makes sense for us. Right now we can't call a student "100% complete" in the course until she's clicked a Submit button for every last assignment, even if she's lazy and/or difficult and willing to take zeros on some assignments. A teacher may get stuck with a 98% student who isn't interacting any longer, but who has for all intents and purposes completed the course (and even passed, potentially). We need to be able to assign the zeros, get Moodle to report 100% to our student information system, and send the report off to the state so we and the teacher can get paid.

• make it easy to tell by a single database query whether grading is actually complete for a quiz attempt (this may be possible now; I'm still working on grokking the manual grading stuff, as you can guess by my initial comments, above )

Thx for the link; it's very helpful (and I only looked at the first paragraph so far ). What I've done for us at this point (and it'll have to be good enough for now) is hack grading/report.php to make an API* out of the code that finds ungraded essay questions, and add a routine ("viewquizzes") that calls the API for every quiz in a course and prints out a table with popup links (b/c this page is CPU-expensive) and the sum of ungraded questions for each assessment. It's not a pretty solution and it should only serve to demonstrate the functionality I'm looking for (in case my explanation is unclear); I've attached it here for that reason.

I'll be gone all of next week, but this week I'm going to try to address the issue of randomly-selected questions not showing comments or taking grade overrides. That should get me more familiar with the entire quiz module overall, so that I can perhaps address random selection of essay questions after that.

Cheers,
Matt

* This is a general complaint I have, and something I'm interested to help fix (if I can). Far too often I find code that I want in an API making the assumption that it's in the business of being a UI. I want to pass parameters and receive error codes and return values, but instead it's busy getting parameters from the URL and telling the human things through the Web browser. We should have UIs using APIs, so that I can use the same APIs to build new UIs. I would guess a lot of this is legacy code, and my [vague, out-of-date] sense of the direction of Moodle development is that we're heading in a very positive direction. So there's an opinion for you, dear reader.

Tim,
As I need no contract but time , I will be able to put more time on moodle as I won't continue my job of chemistry undergaduate program director ib the next months.
Retrieving the subquestions grades can be done nicely if we use the quiz_question_states tables to store them. This ask for a revision of the multiquestion grading process...?

Pierre
P.S. otherwise the subquestions grade has to be recalculated each time...

I have CVS a version that stored the attempts database search and the resulting $question data in the $SESSION so that they are not done again when sorting the table or downloading .

Pierre

As this version does not use new database table, it could be merged to older versions.