Status UNSET in GeoGebra-Aufgaben

[schumaki]

Beschreibung

Für die automatisierte Auswertung von (einfachen) GeoGebra-Aufgaben probieren wir gerade die Möglichkeit aus, in GeoGebra selbst Variablen mit einem Wahrheitswert zu definieren, der dann in der Kodierung als Basisvariable ausgelesen werden kann, z. B. hier:

Mit der Variable "PunktRichtig", die den Wert "true" annimmt, wenn ein (neuer) Punkt auf die geforderten Koordinaten gesetzt wurde und sonst den Wert "false".

Dann kann in der Kodierung darauf zurückgegriffen werden:

Das Problem ist, dass solange sich der Wert dieser Variable innerhalb der GGB-Umgebung noch nicht verändert hat, hier der Status UNSET und kein Code vergeben wird:

Damit kann der Code/Score 0 nur erreicht werden, wenn erst ein Punkt an den richtigen Koordinaten gesetzt und anschließend wieder gelöscht wurde.

Erwartetes Verhalten

Solange noch nicht mit dem GGB-Element interagiert wurde, sollte Status INVALID (nicht: UNSET) vergeben werden.

Sobald ein Punkt gesetzt wurde, sollte "PunktRichtig" ausgewertet werden können, also bei einem Punkt an einer falschen Stelle:

Beispiel

• https://www.iqb-studio.de/#/a/653/145522/preview

---

Versionen

• Schemer 2.7.0
• Aspect 2.12.5

[jurei733]

Ich habe mir das Verhalten kurz in Aspect 2.12.5 und im Schemer/Coding-Flow angesehen. Die Ursache scheint eher im Aspect-Player bzw. in der GeoGebra-Response-Erzeugung zu liegen als im Schemer selbst.

In Aspect werden getrackte GeoGebra-Variablen beim Registrieren initial mit status: 'UNSET' angelegt (GeometryVariableStateService). Der aktuelle Wert aus GeoGebra (geoGebraAPI.getValueString(...)) wird erst über spätere GeoGebra-Events in die Responses übernommen. Zusätzlich bricht changeElementCodeValue() ab, wenn der neue Wert dem bereits registrierten Wert entspricht. Dadurch kann ein initialer Boolean false im Status UNSET hängen bleiben; auch eine Interaktion, die weiterhin false ergibt, hebt den Status dann nicht zwingend auf VALUE_CHANGED. Das erklärt den beschriebenen Workaround false -> true -> false.

Aus meiner Sicht sollte der Player beim Laden des GeoGebra-Applets die getrackten Variablen einmal initial aus GeoGebra lesen und als auswertbaren Response-Zustand registrieren, statt sie als nicht vorhanden/UNSET stehen zu lassen. Alternativ müsste mindestens ein Update von UNSET auf einen auswertbaren Status erlaubt sein, auch wenn sich der Wert selbst nicht ändert.

Wichtig wäre dabei vermutlich, die GeoGebra-Variablen separat initial zu aktualisieren, ohne dadurch automatisch das ganze .ggb/appDefinition als vom Nutzer geändert zu markieren.

Testfall:

• GeoGebra-Variable PunktRichtig ist initial false
• ohne Interaktion bzw. bei falschem Punkt bleibt der Wert false
• die Kodierung sollte trotzdem auf Basis dieses false laufen und nicht bei UNSET stehen bleiben

[schumaki]

Wichtig wäre dabei vermutlich, die GeoGebra-Variablen separat initial zu aktualisieren, ohne dadurch automatisch das ganze .ggb/appDefinition als vom Nutzer geändert zu markieren.

Wichtig wäre aus meiner Sicht, dass das Verhalten analog zu anderen Basisvariablen funktioniert. Das müsste dabei beachtet werden.

(Wenn ich das richtig verstanden hatte, ist z. B. bei vielen als Status DISPLAYED, wenn noch nicht interagiert wurde und INVALID, wenn interagiert wurde, ohne dass etwas eingetragen wurde (also durch Mouse Down, etc.) -- und dieses Verhalten kann dann über die Basisparameter Angezeigt = Wert geändert, Nicht erreicht = Wert geändert und Leerer Antwortwert ist gültig modifiziert werden).

Im konkreten Bsp. oben (Variable "PunktRichtig", die den Wert "true" annimmt, wenn ein (neuer) Punkt auf die geforderten Koordinaten gesetzt wurde und sonst den Wert "false") wäre das erwartete Verhalten aus meiner Sicht:

• bevor mit dem GGB-Element interagiert wurde
  • DISPLAYED als Default
  • INVALID falls Angezeigt = Wert geändert aber nicht Leerer Antwortwert ist gültig
  • CODING_COMPLETE / CODING_INCOMPLETE falls Angezeigt = Wert geändert und Leerer Antwortwert ist gültig
• wenn mit dem GGB-Element interagiert, aber kein neuer Punkt hinzugefügt wurde
  • INVALID als Default
  • CODING_COMPLETE / CODING_INCOMPLETE falls Leerer Antwortwert ist gültig
• wenn mit dem GGB-Element interagiert und ein neuer Punkt hinzugefügt wurde, aber der Wert der Basisvariable (im Bsp. "PunktRichtig") sich nicht geändert hat
  • CODING_COMPLETE / CODING_INCOMPLETE als Default
• wenn mit dem GGB-Element interagiert, ein neuer Punkt hinzugefügt und dabei der Wert der Basisvariable (im Bsp. "PunktRichtig") geändert wurde
  • CODING_COMPLETE / CODING_INCOMPLETE als Default [das entspricht dem aktuellen Verhalten, der Rest allerdings nicht]

Aber ich bin mir unsicher, ob ich das Verhalten bei anderen Basisvariablen richtig verstanden habe. Bitte nochmal prüfen und ggf. anpassen.

[jurei733]

Mein Verständnis nach Prüfung der Statuslogik: UNSET ist hier tatsächlich der falsche Zustand. Eine GeoGebra-Basisvariable, die beim Laden lesbar ist und den Wert false hat, ist nicht "nicht vorhanden", sondern eine vorhandene Antwort mit einem initialen Wert.

Wichtig scheint mir aber, zwei Dinge zu trennen:

1. Wert der GeoGebra-Variable

   • false ist ein gültiger Response-Wert und darf nicht wie ein leerer Wert behandelt werden.
   • Wenn nach einer Interaktion weiterhin false geliefert wird, muss die Kodierung trotzdem laufen können; sonst ist der Fall "falscher Punkt" nicht erreichbar.

2. Interaktions-/Antwortstatus

   • vor Interaktion: eher DISPLAYED
   • mit Angezeigt = Wert geändert: daraus kann wie bei anderen Basisvariablen VALUE_CHANGED werden
   • nach relevanter GeoGebra-Interaktion: VALUE_CHANGED, auch wenn der Variablenwert gleich bleibt
   • UNSET nur, wenn die Variable nicht registriert/gelesen werden kann

Damit wäre der Fix aus meiner Sicht nicht nur "initial false als VALUE_CHANGED setzen", sondern: getrackte GeoGebra-Variablen beim Laden initial lesen, dabei aber den Status analog zu anderen Basisvariablen setzen (DISPLAYED statt UNSET). Bei späterer Nutzerinteraktion sollte der Status auch dann aus DISPLAYED/UNSET heraus aktualisiert werden, wenn der gelesene Wert gleich bleibt.

Ein möglicher Testfall wäre:

• GeoGebra-Variable PunktRichtig existiert initial und hat false
• ohne Interaktion: Response-Wert false, Status DISPLAYED
• mit TAKE_DISPLAYED_AS_VALUE_CHANGED: Status wird vor der Kodierung zu VALUE_CHANGED
• nach Interaktion mit falschem Punkt: Wert bleibt false, Status ist trotzdem VALUE_CHANGED, Kodierung kann Code/Score 0 vergeben
• nach Interaktion mit richtigem Punkt: Wert true, Status VALUE_CHANGED, Kodierung vergibt den passenden Code

Falls fachlich zwischen "interagiert, aber kein Punkt gesetzt" und "Punkt gesetzt, aber falsch" unterschieden werden soll, reicht PunktRichtig: false allein vermutlich nicht aus, weil beide Fälle denselben booleschen Wert haben können. Dann bräuchte es zusätzlich eine Variable wie PunktGesetzt oder eine andere Information aus dem GeoGebra-State.

[schumaki]

Wird in Aspect geändert, siehe iqb-berlin/verona-modules-aspect#1049
Ich setzte deshalb den Status auf Blocked und lasse das Issue offen, um den speziellen Fall der hier beschrieben wird dann noch zu testen.