Developers' Forum

Modifying the question editor for graph questions

Modifying the question editor for graph questions

by Willem Sonke -
Number of replies: 2

Hi Richard,

At our university, we are working on a project aiming to allow graph-based questions in Moodle. After some research we found CodeRunner, and we tried making some example questions. It seems that CodeRunner, with the Graph UI, already satisfies many of our requirements.

However, we noticed that the question editor is not very easy to use for building graph-based questions. In particular, it requires programming to implement checks. We have gathered some feedback from lecturers in the department, and it seems this requirement will hinder adoption by them.

To alleviate this, we want to make it more intuitive to create graph questions. We already implemented a custom question template containing a series of methods, each checking a basic graph property. These can be used together to quickly check desired properties of the result. To simplify the procedure further, we plan to modify the question edit page. We drew a mockup to show what this could look like:

Mockup of a test editor

Before diving into the code ourselves, we were wondering if you have ideas on how this could be implemented best. Do you think it would be better to develop this as part of CodeRunner itself, or to split it into a separate Moodle plugin?

Arthur van Goethem and Willem Sonke
Dept. of Mathematics and Computer Science
Eindhoven University of Technology, The Netherlands

In reply to Willem Sonke

Re: Modifying the question editor for graph questions

by Richard Lobb -

Hi Willem and Artur

Good to know you're finding CodeRunner useful and interesting to hear about your use of the GraphUI.

I appreciate that the question authoring UI isn't very user friendly but it is at least fairly consistent with the standard Moodle question authoring UI. I think it would be difficult to incorporate a customised GUI-fied authoring UI just for questions using the GraphUI in a clean way that was consistent with the various other CodeRunner UI components (currently AceUI, TableUI, GapFillerUI, GraphUI and HtmlUI). It would be possible with major refactoring to extend the existing UI plugin API to allow companion question-authoring UIs as well, but it would be a massive effort and I don't think the complexity would be warranted. CodeRunner has already been accused of suffering from feature bloat. Also, your proposed UI, while it looks very nice and quite likely perfectly fits your own team requirements, wouldn't cover many of our own GraphUI use cases, and GraphUI is already a niche market.

So unfortunately I think your own project lies outside the main CodeRunner development path.

Off the top of my head I can see three ways you might proceed:

  1. Write a completely independent question-authoring program (not even a CodeRunner plugin) that outputs the Moodle-XML representation of CodeRunner questions. Import those questions into Moodle. This is the easiest approach from a coding standpoint but is very clumsy (unacceptably so?) when you need to do any question maintenance. Certainly not a good long-term solution but perhaps worth considering as a way of getting yourself up and running. 
  2. Fork CodeRunner and rewrite edit_coderunner_form.php to display the HTML you require. This is probably the next simplest option, but has the disadvantage that you'll have trouble maintaining compatibility with standard CodeRunner over time. It's also not quite as simple as it may first appear because (assuming you want to be able to run standard CodeRunner questions on the same server) you'll need to change the question type to something else, which will affect a lot of code, albeit in a straightforward way. Also there is a fair amount of JavaScript support code (see the amd/src folder) and some of that will need changing, too.
  3. Write a new Moodle plug-in that allows you to create or edit CodeRunner questions independently of CodeRunner itself. I think this would be the nicest solution but is also probably the most work. It gives you reasonably good long-term compatibility with CodeRunner itself, although you would still need to adapt your code if/when CodeRunner modifies its database schema.

A big advantage of (3) is that question authors who wanted to go beyond the GUI-fied interface you provide will still be able to use the more-powerful code-based approach. I predict this will happen almost immediately, following the Software Engineering rule "People seldom know what they want until you give them what they ask for"!

Good luck

Richard

In reply to Richard Lobb

Re: Modifying the question editor for graph questions

by Willem Sonke -

Hi Richard,

Thank you for your extensive answer!

After some careful consideration we have decided to choose the second option and fork CodeRunner to give a clean setup for GraphChecker, while being able to build on the great setup CodeRunner offers. Our project is slowly taking shape and by now we have a preliminary alpha version that is giving us the behavior we hoped to achieve. Hopefully within reasonable time we will be able to publish a initial version. At the moment we are in the process of ensuring that CodeRunner and GraphChecker can run successfully next to each other. So far everything is going fine, however we ran into one issue.

After changing the name of the plugin, we noticed that qbehaviour_adaptive_adapted_for_coderunner refuses to run for any questions that are not CodeRunner questions (see here). We were wondering if you would be willing to update qbehaviour_adaptive_adapted_for_coderunner, so that it also accepts GraphChecker questions. (An alternative would be to make a separate qbehaviour_adaptive_adapted_for_graphchecker, but that seems redundant.)

Alternatively, we found a topic where you mention that you would like for CodeRunner to do the caching in the same way that the STACK question type does it, so that maybe the qbehaviour_adaptive_adapted_for_coderunner would not be necessary at all anymore. Would you think it makes sense for us to look into this approach as well?

Kind regards, Arthur and Willem