Add measure functionality to measure glyph #354

Closed wekitecs closed 2 years ago

In GitLab by @wild on Apr 1, 2021, 15:34

Where the measure glyph is used, allow the learner to measure something from point to point (and indicate the target location of where the glyph was placed). Store the measured value into the xAPI, so it can be queried in a future action step.

In GitLab by @wild on Jun 25, 2021, 19:58

Tested it now - looking good, though tweaks are needed:

S->E: wouldn't A->B be more common?
not sure about the glyph staying on top of the ruler in playmode, maybe we should remove it and rather make the ruler look a bit more fancy? This is what Google uses: https://cdn.vox-cdn.com/thumbor/bF6itWRarPTofQNTTx5f28HNdAk=/0x0:2394x1344/920x613/filters:focal(1006x481:1388x863):format(webp)/cdn.vox-cdn.com/uploads/chorus_image/image/60149503/Screen_Shot_2018_06_22_at_10.17.28_AM.0.png, this is what Apple uses: https://support.apple.com/library/content/dam/edam/applecare/images/en_US/iphone/ios14-iphone12-measure-take-single-measurement.jpg
Measuring is not only relevant for authoring (though useful: can show how long something needs to be). It is relevant also for playmode, so the learner can be asked to measure something (e.g. forehead length on neandertal skull), which then gets stored to the xAPI, and can then later be picked up in a later action step in MirageXR or in assessment in Moodle

In GitLab by @a85jafari on Jun 26, 2021, 13:42

I will fix the first two points, but the third one need more discussion. I did not get exactly what do you mean. storing in xAPI or ARLEM too? For xAPI we can store the verb like "measured" but not more data like 50cm, as I understood from Boris

In GitLab by @a85jafari on Jun 26, 2021, 16:56

Please open a new ticket for the xAPI, so maybe someone else with xAPI experience like Benedikt take that ticket.

In GitLab by @wild on Jun 30, 2021, 17:03

Checked with Boris - we should definitely be able to store the value in the payload (e.g. via "extension"). Do you want to ask him how or shall I?

In GitLab by @a85jafari on Jun 30, 2021, 17:25

This is his answer last time I asked him about storing more data than the verb:

"There is just one thing that should be mentioned here, you need <actor, verb, object>. The actor is the user, the verb is "measured" (actually the full UID is needed, will let you know when I find it) and the object. For the object you cannot use "50 cm" as this is another qualifier, rather you must use the actual object measured. This 50cm will have to be added later, as we don't yet have the capability to save this yet. It would be best if we could talk about it in the meeting tomorrow."

In GitLab by @wild on Jul 1, 2021, 11:25

Documentation says: "We’ve also added to the “extensions” field, where we can put arbitrary key (URI) / value pairs that are custom to a particular application (or convention)."

But even better, I think, is to use "result": "And in the case of a statement that records an interaction between the actor and the object, the result can have the actor’s response. In that way we could say 'Sally answered ‘Question A’ with the response ‘Choice B’ in 8 seconds, and was correct'."

This "results" part is on the same level as actor, verb, and object and looks like this: "result": { "completion": true, "success": true, "extensions": { "http://example.com/flight/averagePitch": 0.05 } }

Here is the full documentation: https://github.com/adlnet/xAPI-Spec/blob/master/xAPI-Data.md#result

This is currently not implemented in the i5 services, but in the TinCan implementation we used originally it is: https://github.com/RusticiSoftware/TinCan.NET/blob/master/TinCan/Result.cs

@BorisJov @BenediktHensen what do you think?

In GitLab by @wild on Jul 1, 2021, 11:29

Btw: all of the result fields are optional, so we can simply just log:

"result":{ "extensions": { "https://schema.org/Distance":"50 cm" } }

The identifiers need to be IRIs: https://github.com/adlnet/xAPI-Spec/blob/master/xAPI-Data.md#iris

In GitLab by @wild on Jul 1, 2021, 11:58

Interesting question in this context: should we store the value directly, or should we store a link to the Moodle plugin's stored value?

"result":{ "extensions": { "https://schema.org/Distance":"50 cm" } }

or

"result":{ "extensions": { "https://schema.org/Distance":"https://arete.ucd.ie/moodle/areteplugin/resultvalue/548478" } }

or both?

"result":{ "extensions": { "https://schema.org/Distance":"50 cm" "https://schema.org/Distance":"https://arete.ucd.ie/moodle/areteplugin/resultvalue/548478" } }

In GitLab by @BorisJov on Jul 1, 2021, 12:41

Between the context-extension and result-extension there is really no implementational difference. As for semantics, I would agree that as per the xAPI documentation the result values should be used for this, as they store "measured outcomes".

As for implementing, the i5 tool indeed doesn't support this. I spoke with Benedikt already about extending this library for adding names to verbs and objects so I can also extend it to include result values. This is the part I was talking to Abbas about when I said we don't currently support it.

As for the exact value stored, I would go with both for now, just to make sure. Moodle data could be lost or moved or similar and from the other side it's good to have a reference for the actual value.

In GitLab by @wild on Jul 1, 2021, 13:06

Thanks for the update!

Leaves just two questions: What is the timeline and who is implementing it into i5 :)

WEKIT-ECS / MIRAGE-XR

Add measure functionality to measure glyph #354