Feature Request: "Context-aware" Block

[LukeLongworth]

Kia ora,

This is possibly a long shot, but I thought I'd ask!

(Ah, I just realised after typing the whole thing out that this specific request requires re-generating the whole question on every page load which probably makes this infeasible. I'm still posting it in case anyone has clever ideas to sidestep the question caching process for just this block, or hijack the existing question versioning somehow, etc).

I frequently want to re-use questions between courses (using a shared question bank), but sometimes need to make minor changes. Any minor change means I need to make a duplicate question, so I end up with a handful of questions like "Implicit partial differentiation (EMTH210)" and "Implicit partial differentiation (MATH201)".

What I would really love is a block, perhaps something like [[context]], that will check a course ID (or title etc) and only display the relevant information. I'm envisaging something like:

<p>For a similar example see [[context id="EMTH210"]]Section 3.1.2[[id="MATH201"]]Section 2.1.1[[/context]] of the notes.</p>

I anticipate difficulties with repeating courses - how would I ensure that all iterations of EMTH210 will trigger the relevant id tag? Could there be a central "hub" that works as a "if id='1234' then course='EMTH210'" in the Admin UI? Then you could organise this once per semester.

If none of the IDs match I would suggest that either nothing displays, or a warning message to contact your teacher displays.

Other places where this would be useful would be default marks or penalties. I suspect this would be more difficult - do these fields ever touch the block system at all? It would be useful to me because some of our courses prefer a short-quiz high-penalty model, with others preferring a long-quiz low-to-none-penalty model. Then I could use the same question in MATH101 with a 10% penalty and in MATH102 with a 50% penalty. If nothing matches here then I think an error needs to be thrown that prevents saving the question.

Another use case could be defining notation or display standards. For example, a math course might prefer Liebniz notation for a differentiation question whilst a physics course might prefer function notation or dot notation, but otherwise be happy with the exact same question. One course might use a certain colour scheme in JSXGraph to denote some meaning, whereas another course might prefer a different one.

In the absence of this being a possibility, I will happily accept any suggestions for how best to notate/identify questions like this in a question bank/quiz. At present I'm considering something a little unwieldy like titling my questions E210/3. Implicit partial differentiation and M201/2. Implicit partial differentiation to denote course and week number, and ensuring they're in the same/nearby folders.

Thanks!

[sangwinc]

Thank @LukeLongworth, an interesting suggestion.

I think we should keep the stack plugin (qtype_stack) as basically a stateless function. Well, we do store state in inputs of course, especially for things like JSXGraph. But, we don't have user id, course id, etc. I suggest we keep it that way. There are a couple of reasons. (1) STACK is used in Moodle, ILIAS and the API. I want materials to be independent of platform. (Not impossible to fix, but extra work), (2) clarity of design.

I've said this before, but I'll repeat it here. It's not clear in the design where a single "question" should begin and end! E.g. what code should be core supported libraries (ATAlgEquiv should be...) and what should be in a single question (e.g. bespoke validation functions). We've already made is possible to share small libraries of Maxima code between STACK questions with the inclusions (https://docs.stack-assessment.org/en/Authoring/Inclusions/ ) Thanks for your contributions here @LukeLongworth, it's much appreciated. (I'd like this reply to be useful to everyone reading the thread.) This does not address this problem of course, but it's part of the picture.

A more recent innovation (v4.8.0) is the STACK library of questions we distribute withe the source code. That gives us the exciting option of "template questions". Again, not quite what you're asking for, but closer. If we update a template then should questions based on it also update? Currently "no", you load the template and change it.

I'm also nervous about sharing questions between courses as roll-over year to year is really complicated. So, I'd rather not provide cascading template functionality within STACK itself. Actually it's nothing to do with STACK questions. You might well expect that kind of thing in any Moodle question.

Instead, I'm going to suggest we develop workflows around templates outside Moodle. We can then use the new gitsync plugin (https://github.com/maths/moodle-qbank_gitsync). Different branches of your (external) git repository can be used for each course. If you improve a question in once course, you can choose to include those improvements in both and retain the modifications as well. I don't think Git is exactly the right data model, but it's close. We will see! Further, the history in git gives clarity on what was changed and when.

I'm intending to create a text-based format for STACK questions (perhaps YAML). That solves a lot of other problems, including cut and paste PRTs between questions. It also allows us to cascade from one question template through a sequence of modifications to the final question intended for a particular course. At that point you use gitsync to populate the course. Gitsync works in both directions (import/export) so when you have a bug in a question, or perhaps improve the feedback in one course the changes can be syntonised between both.

@EJMFarrow has put a lot of the links in this chain together already. The next priority is simplifying the editing experience, to better support newer users. Then we'll look at the text-base editing.

I'll be quite honest @LukeLongworth, to address your educational purpose in the example, I really don't like putting in explicit references to sections of notes. I used to do this, but even within a single course they are fragile year to year and require constant maintenance! I'd rather repeat the explicit section in the feedback itself to make the question self-contained (where possible).