Quiz

Hello Joshua,

I understand your concerns about using third party qtypes.

I can't answer for OU qtypes but surely the problem is that when something is included in core, this is both a commitment for the quiz and question components maintainer to take care of it in the future, and a loss of freedom for the organisation who paid to have it created because its future evolutions have to be approved by integrators and moodle.com .

For ddmatch created by Adriane Boyd during GSOC a few years ago, don't forget it's just 99% the same code as match with just one more field a few lines changes here and there and a different renderer. Now that javascript and Ajax are everywhere in Moodle I really think it doesn't make sense that core match don't offer a drag and drop UI. Really !

A plan could quite easily be made to integrate ddmatch functionnalities in core match.

• Add the needed field answertextformat and another boolean one (lets call it dragdrop, with default false) to indicate if the question is to be rendered with drag and drop during attempt (more on this later).
• Modify the code in all place to allow creation of question with drag drop functionnality enabled or not via a new setting in form.

• Modify the renderer so that question is rendered as drag and drop if a) the relevant setting is true for this question, b) visitor's browser allow this (not sure of this, it surely imply browser sniffing wich is quite prone to break IMHO, but anyway we have to make sure the question is still working for screen readers). If we need to render it as non drag and drop, apply html_to_text to answertext before rendering it in a menu item so that nothing bad can happen.

• Create an admin tool so that admins can migrate all existing ddmatch questions as match questions with dragdrop enabled, and maybe also do batch enabling of drag and drop setting on existing match questions

The only real problem I see is that, as I said above, this imply that somebody will have to maintain this code once it is in core !

Thank you for raising this. I would really like to know what the community thinks about this.

On a technical level, it would be very easy to add most of these question types to Moodle core. The code exists, it just needs to be made into a patch which is a few minutes work.

There are two big questions as I see it:

1. Is this (adding more plugins to Moodle core) the right thing to do? The answer depends on the particular plugin, it might be right to add drag-and-drop. It will almost certainly never be right to add STACK or Opaque (even though they are very cool) becuase they are too specialised and require additional set-up. The alternative to more stuff in Moodle core, is to improve the admin interface to the point where we have an app-store to let admins install plugins wiht confidence. (Firefox is a good example of how to do this.)

I think this disucussion of the general principles should take place in a wider forum than this one. Perhaps https://moodle.org/mod/forum/view.php?id=8052 is the right place. That is, it would be good to develop a set of general principles to apply when making the decision about a specific plug-in.

2. The other issue is where the funcitonality in add-on question types overlaps with the core question types. For example, I think it would be a bad idea to have both varnumeric and calculated qtypes in Moodle core. That would be too confusing. Therefore the only option would be to merge them somehow, or provide an upgrade path. (And example of this is the new survey module, which should replace old survey, questionnaire and feedback modules with a new super-module.)

Serving two masters is not an issue in this case. (In my work on Moodle, it rarely seems to be, I am please to say.) Moving a qtype form contrib to core makes some things a bit easier and some things a bit harder. We can cope doing it either way.

What I don't want to do is abuse my position as quiz maintainer / OU developer to get our plugins into Moodle core. That is why I would really like to be guided by the community (all of you) about what is the right thing to do here.

Actually I agree with all previous posts. For me this is (one of or perhaps) the most important topics about Moodle development. 

IMO Joshua expressed very well our concerns as Teachers and Moodle admins about the Quiz module. 

For me, as a science teacher the MAIN reason for using moodle is the quiz engine. As Marcus wrote 'there are very few opportunities for GPL Web quizzes and none of the standard of Moodle'. 

Tim's concerns about how to manage the addition of contrib software is full of sense. I'd like that install plugins in Moodle was as easy as it is install addons on Firefox. I've just finished to upgrade to the latest firefox from and old Iceweasel and most of addons were recognized and updated automatically. I wish one day moodle upgrades were so easy! 

My problem: I installed some years ago a new question type 'imagetarget' in moodle 1.9.x I created many questions using this questiontype and for some topics they represented until the 40% of the question bank. Some months ago I upgraded to 2.3 so now I will have to review manually all these questions to re-use them in moodle 2.3 

What to do? In my opinion and as I already said before, quiz module is one of the most powerful modules in Moodle, so I would encourage Tim to go ahead adding the new questiontypes from OU into moodle core. 

I don't understand why the quiz module is not more popular. The e-assessment team at OU are amazing. In the last three Spanish Moodlemoots there were neither keynotes nor workshops about the Quiz module. I can't understand it!  

Best regards from Vigo (Spain) 

Toni Soto

Another program to look at is the Amahi Home Server. Their plugin app store is like Firefox's plugins where the user only has to click to install and uninstall, and the program is up and running. It could be a different implementation (coding) you might want to look at.

P.S. Amahi charge for some apps because they previously relied on donations and didn't have a business plan. But Moodle seems to have a good business plan to make them sustainable.

Thanks to Joshua for raising this topic and to all who have taken part so far.

As the author and maintainer of the REGEXP question type I have mixed feelings about the inclusion of contributed question types in Moodle core. Indeed my point of view has changed over the years.

Initially, I was quite proud of my creation  (like all creators), and obviously felt it ought to be included in Moodle core, where it would be useful to many users.

However, inclusion in core would mean transfer of maintenance to the Quiz maintainer (Tim). This transfer of responsibility would mean first that I would have to revise my code to make it impeccable in order to be accepted by Tim. That would be a good thing. But it would also mean that I would lose the freedom of making subsequent modifications & improvements. In a way, my creation would escape me, and I would not like that. Not to mention that obviously Tim does not have the time to maintain an excessive number of question types.

As pointed out by Tim in the current discussion and Martin in this more general discussion, the best solution is to keep core question types to the strict minimum obvious types. From my point of view, there are too many already e.g. with no less than 3 calculated types! And at the same time, to quote Martin, "move towards pushing everything into the Moodle plugins database and using manual/automatic means of installing/updating plugins in any given Moodle."

This would not solve the problem of contributed plugins not being updated to follow the current rapid flow of moodle versions (too rapid for developers, as has been voiced quite a few times on these forums). Not to mention "orphaned plugins" no longer maintained. But that is the common lot of open source and the usual answer is "because it's open source, if you badly need it, you can update it yourself or - it you don't have the needed skills - persuade someone else to do it for you'.

In conclusion, rather than saying there is "a glut" of contributed questions in the plugins repository I would say it is great to see so many instances of creativity there. There only remains a user-friendly mechanism to make those plugins available to those who need them.

Joseph

Can I thank everyone for their contributions to this thread so far. I don't think we are anywhere near a consensus yet. (If you disagree, please try to summarise what you think the consensus is). However, a lot of good points have been made. Please keep going if you have more to add.

I've been thinking about this off and on over the weekend.  I believe that you all have convinced me that I started arguing for what I think we need in the wrong way.  

My real concern is the lack of improvements in the core question types.  I was initially thinking of this as just add in more question types and problem solved.  But as I've thought about it more, I'm beginning to agree that you want to only have questions types that are widely applicable and leave the rest as plugins.  

So to that end, here is a proposal list for people to fire away at (and convince me of other stuff).

1) I think core matching should be replaced with Drag and Drop Matching.  It is an obvious improvement and replacing the old code with the new one doesn't add more long term mainteance issues.

2) I think that the core Cloze type should *probably* be replaced with the upcoming OU replacement for Cloze.  Having the ability to do a multipart question as a single unit is huge.  This allows you to randomly select a set of questions that all match each other.  I've been doing this with Cloze since 1.9 but Cloze is crude and cumbersome.  If the OU replacement is better then it should replace it.

3) I think one of the drag and drop image type questions (Drag and Drop Onto Image or Drag and Drop Markers) should be added to core.  Map/diagram/chart/graph labeling is common in many different disciplines.

4) I think Algebra, PMatch, STACK, and other special use case and/or complicated question types should stay in Contrib.  The math teachers at my school would probably kill me for saying that about Algebra but it really is only useful in Math and a few Science courses.

5) In general, when there is better question type out that duplicates and expands the functionality of a core question type then it should be evaluated to replace the core type.  Extra question types should only be added when there is new functionality that is widely useful with minimal duplication (the Martin rule).

6) There should be a better plugin management system.  I'm particularly fond of Marcus's proposal for quickly checking plugins after a major version bump and marking the ones that have obvious problems.

7) There should be periodic contact with contrib developers to determine if there are plans to continue development for updated versions or not.  Then these could be marked appropriately in the plugin database.  This would help to identify orphaned plugins and let the community take it over.

All of this is more work for someone else other than me.  I'm just a teacher, although the truth is that you all have inspired me to start taking some web development classes.  With that being said, the first part of this proposal is just replacing things with existing code or adding in 1 new question type.  That doesn't seem too bad to my ignorant thought process.

As I said earlier, I'm putting this up to have stones thrown at it.