Reporting multistage activities

Let me add some idea about what I'd like to develop so that probably you can help me to spot where to patch. It is quite obvious to note that there is out there a large number of GGB activities that one cannot use for automatic assessment because they need translation into your language and/or they are devised to illustrate a concept not for assessment. I am working on automatic translation but this will not impact this plugin so I will not detail this feature here.

In the hope of harvesting a large number of GGB activities for auto assessment the second target is to take a GGB activity with randomized values that one can mark as correct or failed and turn it automatically into an assessment test by repeating e.g. five times the activity with different random values. I am considering several options for this but none needs to modify this Moodle plugin, again.

So you might wonder why I am telling you all this. Well, in this framework, it becomes apparent some difficulties in reporting the assessment. Your plugin offer the grader a snapshot of the state of the GGB construction JUST AT THE END of the process. You might say the student that she/he scored 2 out of five but you cannot show her/him the 3 mistakes and this is embarrassing. For most activities in the GGB site It is not difficult to add standard js code to the .ggb to snapshot the GGB view at some meaningful places. You need just a shallow understanding of the GGB activity implementation and some heuristics and you will autoconfigure the js additional code to snapshot the mistakes in most of the cases. To be effective one tends to oversample snapshots and this grows too much the space for the ggbs to be stored into Moodle. A rough estimate of the space needed by a teacher to store all this for all the classes for a whole school year (sometimes at the end of the year students failing to pass starts a lawsuit and you are asked to provide evidence for all the notes for all the year so...) lead me to a figure of 64GB that is too much for the AMP server. I introduced some delta encoding of the sequence of XMLs that encodes the snapshots and this could reduce the MySQL burden a lot. IN THIS FRAMEWORK (again) it would be nice to have an option to thick (on per GGB basis as for the random thick) to tell the plugin to call some hooks (i.e. JS functions) that the js code in the GGB could expose. The whole API for these hooks could be difficult to foresee now but surely there should be a hook as goingDown() to be called before storing the GGB and another as TeacherView() to be called when the .ggb is loaded by the teacher for review.

Let me add that tackling this problem could be profitable for this project too, cause you could run into problems if storing the .ggb for too many attempts. There is an obvious redundancy in this. In this view delta encoding XML in JS on the client could become a part of your plugin and you can offer a doSnapshot() hook to those willing to use it. I can assist you in this transition. Simply I had found that diff_match_patch.js from Google works fine on XML strings returned by GGB and deltas are just a dozen of characters. So I can enjoy oversampling and report correctly student's work. In the end deltas just have to record students work and this, conceptually, most of the time is just condensed to writing down a two digit number or fraction.

_Originally posted by @TWINGSISTER in https://github.com/projectestac/moodle-mod_geogebra/issues/65#issuecomment-1038038663_

projectestac / moodle-mod_geogebra

Reporting multistage activities #69