Hello Tim,
since some time we can add tags to quiz questions. I've tried to find a process to use the tags after editing the question, i.e. for searching for questions. Is this feature not yet implemented or did I search at the wrong place?
This week we got questions from two users about using tags for students for preparing exams. The idea was that student can use tags to select questions related to the tags to prepare for exams. Any idea how to implement such a feature?
Well, lots of ideas for what might be possible. No actual time to implement anything.
Hello Tim
what is the development idea to add fields for tags but not to make the usable.
Ralf
I expect the explanation is that Tim wanted to get the tags feature into the question engine (in moodle 2.1), and then he had to leave the actual uses of that feature to a further version (for lack of time to implement it sooner).
Joseph
Well, I can understand this. Such incomplete feature should be hidden/disabled by code or site setting until they can be used.
Oh No, no please don't disable or hide this feature !
It's very important for me (and I think other Moodle users) to be able to enter tags when I create questions (even if I am only able to use them "latter") because if not it would be a very big task to review all existing questions to add tags when this feature will be finished !!
No problem with the suggestion that you can enable it. But it should be disabled per default setting. So user that don't wnnna use it don't see it.
The form for creating quiz question is a big mess from usability perspective. Its not well structured and confusing. People don't get a quick overview where they have to do what.
It would be much better if the answers were structured in a three column table and an option to de/activate the editor for feedback.
The general/specific feedback fields should be shown together and better structured.
Ralf "The form for creating quiz question is a big mess from usability perspective."
Yes, many moodle users agree.
Interesting suggestions have been made by Colin Chambers (and participants) in the Refreshed question authoring interface discussion where I suggest that discussing these matters be continued.
Joseph
+1 With Ralph on this. If it dosn't work it sohuld be displayed by default. It's not a feature until it works.
I knew that consideration was being given to simplifying the question editing page, that's going to be quite a challenge. I'd missed that discussion, I'll look at it late rand see if I can contribute anything to it.
I'm beginning to implement tags within the question bank. I don't know if the implementation will be accepted for integration, but I'll at least make a patch available. I'd like to hear any suggestions or comments on how you'd like to see it done.
Here's what I have in mind at the moment as far as the UI. This is the existing question bank UI:
We'd add a field to find questions by tags:
Hopefully we could do autocomplete, similar to the autocomplete the Moodle Tracker has:
As a second question, I'd love to do this as a plugin or something so people who want it right away can have it right away. Based on a quick look at the code, it appears unlikely that there's a way to do that. If anyone who is more familiar with the question bank than I am has any thoughts on that, I'd love to hear them.
This is too much clutter to add to the UI in Moodle core.
I don't think it is possible to do this as a plug-in.
My suggestion for how this should be done in standard Moodle: Near (or in place of) "Select a category" add an "Advanced search" button. That should pop-up/reveal a little JavaScript dialogue where you can control all sorts of searching / sorting in the question bank.
You can probably implement this as a fairly small patch to Moodle core, that links to more code in a Moodle plugin (e.g. local/qbanktagsearch). You probably just need to add a few function calls in question/editlib.php, in the question_bank_view class, to call your code.
> that links to more code in a Moodle plugin (e.g. local/qbanktagsearch).
Let me check if I'm understanding you correctly. Is your suggestion to abandon ever finishing tags in Moodle itself, and only have them actually work via a local plugin?
I'm not saying that's unreasonable - integrating any improvements in Quiz or Question bank is quite a task, I just want to be sure I'm understanding your suggestion.
> That should pop-up/reveal a little JavaScript
Any thoughts on how that relates to the #1 rule of of JavaScript in Moodle?:
http://docs.moodle.org/dev/JavaScript_guidelines
I am not suggesting the we abandon ever finishing question tags in Moodle core.
I am suggesting that it will be very hard to get question tags right. We need to make all the desired functionality available, without cluttering the interface too much for people who don't care about tags.
Therefore, we need experimentations with possible solutions to try things out and learn more. So, it is good you are planning to try something.
But, don't expect your first attempt to be likely to be good enough to be integrated. Hence my suggestion to make this as much of a plug-in as possible. (That is, put the bulk of the code in a local plug-in, just a few calls to it in core code.)
If what you do is good enough to go into Moodle core, the extra work of loving the functions from local to somewhere else, and renaming them, is tiny compared the to amount of work you will do to actually implement the functionality.
In the mean time, if you can think of small ways to change Moodle core, so that plugins can have more control over how the question bank looks without core code changes, then please suggest them.
I read Tims post just after I woke up this morning and was rather intrigued by the new technical term of "loving the functions". It seemed an appropriate term and I guessed it meant that they would get used over time till they were widely accepted and then would be integrated into core code. I was quite disappointed to realise it was just a spolling error and should have read moving rather than loving.
But to address the real issue, Tags are potentially very useful and as they could be used very widely it would be good to get the implementation right.
Thank you for the clarification. I am trying very hard to find some ways to reconcile the high bar of "good enough to be integrated" [into Quiz] with the need to get things done and serve our users' current needs on a reasonable schedule.
> I am suggesting that it will be very hard to get question tags right.
You might be right. It appears the functionality itself is harder to do elegantly than I first thought. It's turning out to be hard to do with a) minimal changes to existing code b) while maintaining database compatibility with different databases and c) without using code that's just plain gnarly and therefore subject to derision upon review.
> But, don't expect your first attempt to be likely to be good enough to be integrated.
Hopefully those doing peer review will either offer suggestions on how to make it more elegant, or excuse the fact that bits may be less elegant than we'd like, partly because the RDMSs don't all have the functions we'd like them to have.
> Hence my suggestion to make this as much of a plug-in as possible.
I see that Quiz has a question bank class which inherits from (subclasses) question bank itself. I'm currently planning to inherit from that and inject the new object over the Quiz version of the class.
> In the mean time, if you can think of small ways to change Moodle core, so that plugins can have
> more control over how the question bank looks without core code changes, then please suggest them.
There is one major suggestion I've come across so far:
Column types can add joins to the query and can add fields to be selected. However, it's hardcoded that the only parameters that can be passed are category IDs, so you can list questions by category, and only by category:
list($catidtest, $params) = $DB->get_in_or_equal($categoryids, SQL_PARAMS_NAMED, 'cat');
$this->sqlparams = $params;
My suggestion is that just as column types can add to the select list and can add joins, also let them add parameters to be used in those joins.
It's OK, I understand about the constraints of trying to implement stuff with minimal changes to core.
Coming to the point at the end, I don't think it is columns that should add new WHERE clause bits. I think we need a new sort of thing, question_bank_search_condition, instead of question_bank_column. Then the question_bank_view would accept a list of those, to control which questions are shown. Each one would generate an SQL expression to go in the WHERE clause, and they would all get ANDed together. The search_conditions would probably be allowed to suggest extra joins, if they need to.
Of course, that would require code changes to add that infrastructure, but that seems like a good API change to me.
Of course, to replicate the current behaviour, we would need one new class question_bank_category_list_search_condition. You would need to write question_bank_tags_search_condition.
Thanks for your comments, Tim. That sounds good to me.
At first I misunderstood and read that as you were suggesting REPLACING question_bank_column with a different type of class question_bank_search_condition, which would be a major rewrite. I then understand I believe you're saying ADD question_bank_search_condition to control the where clause, while question_bank_column continues to control the select list.
That'll be handy for other things, like a search_condition that can search answers could let you find all of the questions with an "all of the above" answer, questions which should not be randomized.
The question_bank_search_condition approach as suggested by Tim seems to work well so far. I don't know if anyone (Tim?) is interested, but attached is a working draft of the question_bank_search_condition approach. I'd be happy to hear any comments anyone has before I continue to finish this out into a version that can be submitted for integration.
The 100-line patch attached moves the "showhidden" and category WHERE clauses to the new approach. There is a tiny subclass called question_bank_search_condition_hide which replaces $showhidden and one called question_bank_search_condition_category which replaces / moves the inline category filter.
It still needs at least a check for coding style, tests written, and probably another test class to further validate the approach, but it seems to work well with a neat little patch. Any other thoughts at this point?
This approach does seem to work nicely.
Yes, you need to fix your coding style
Also, it would be easier for me if you could share your changes on github. Feel free to ask if you want help with that. It is really worth scaling the git learning-curve.
One thing I don't like about your proposed design is the $where and $params fields in the base class. That places too strong a constraint on how subclasses work. I would implement it like this:
abstract class question_bank_search_condition {
public abstract function where();
public function params() {
return array();
}
}
/**
* This class controls whether hidden / deleted questions are hidden in the list.
*/
class question_bank_search_condition_hide_hidden extends question_bank_search_condition {
protected $showhidden;
public function __construct($showhidden) {
$this->showhidden = $showhidden;
}
public function where() {
if (!$this->showhidden) {
return 'q.hidden = 0';
}
}
}I've done further testing and refinement, including implementing a "search by tags" subclass, and running Code Checker. I have a question about:
> Also, it would be easier for me if you could share your changes on github.
> Feel free to ask if you want help with that. It is really worth scaling the git learning-curve.
I've read three requirements or requests which seem to contradict:
1) Share a new feature / fix as a single commit
2) Do not combine commits after pushing them to github
3) (From this thread) share a "draft" version on github
#2, from the Git book, was validated when I tried combining commits via git rebase -i HEAD~3. That was a nightmare. It seems the book is right - you shouldn't muck with commits after PUSH.
How do you get to #1, share the "final" version as one commit, without violating #2? The only way I know of is to hold off on commit and push until it's ready. That doesn't allow for #3.
I'll get you something to look at that works fine in my testing as soon as I know how to do so without causing breakage of my Git in regards to #1 and #2.
1) is just wrong. A more accurate version is "When you think a new feature is complete, try to submit it as a small number of logical commits that makes it easy to understand they change". For many things 1 is the correct small number, but for larger changes it should be more.
While your work is in progress, it may be better to keep all the history, to help people who are following along.
2) is better, but still an over-simplification. Given 1, a more accurate version is "During development, you may push code to github with the idea that others will be reviewing it, or maybe experimenting with it. In this case, give your branch a name like ...temp or ...wip, and re-base it if necessary. After you have pushed finished code to github, and other people have started building on top of it for real, don't rebase."
3) should now be clear.
To re-push after a rebase, use git push -f ...
Thank you for the explanation of git policy.
Thank you also for your blog page fixing-bug-in-moodle-core-mechanics.html. The step-by-step process their is quite helpful as a compliment to a wider understanding of how things work.
If anyone would like to follow the progress of this, or vote for it, it's in the tracker:
Screenshots of a prototype UI adjustment that makes the interface simpler than it has been, in a way that is consistent with the new "show more" approach to be used in Moodle. Comments are welcome.
Dear Ray and all,
Very glad to come across this thread today, thank you for your work.
May I suggest a couple of use cases:
- Have a quiz that draws X number of questions at random from a category, as currently, but with filters applied to that category (e.g. based on tags). For example, we are tagging all questions on a range of dimensions, such as difficulty, learning outcome (basic recall, understanding, etc), and a reference to the content. We'd love to have a quiz that helps a student revise questions in a particular section in the notes and/or at a particular learning outcome. Thus if new questions are added with matching tags, they'd get added to the pool for this quiz.
- Allow these filters to be parametised via the URL. This would allow the values of the filters (e.g. the actual reference to the notes) to be set dynamically. This would avoid the need to create different quizzes for different tag values.
Thanks again for your work,
Martin
The infrastructure to search the question bank based on tags is now integrated in master and should be included in Moodle 2.7 when it's released. Though the underlying infrastructure is included, the GUI to actually find questions by tag within the question bank currently requires a 3rd party plugin from TEEX. We plan to submit this to https://moodle.org/plugins/ upon the release of 2.7. The current plugin allows one to find questions which are marked with any number of tags and also narrow it down to those questions which are NOT marked with some other tags.
For example, one could find questions tagged "Math" but NOT tagged "Calculus" to find non-calculus math questions.
An early version of the plugin is available on the tracker.