H5P Zustände
Die Sicht der Lehrenden und der Entwickelnden muss getrennt werden, da die Lehrenden lediglich interessiert, ob ein H5P nutzbar, nicht nutzbar oder noch ungeprüft ist. Hingegen muss bei der Kommunikation zwischen Autorentool und der 3D-Lernumgebung mehr Information übertragen werden.
Beachte auch: H5P-Zustände Autorentool
Mapping der H5P-Zustände: Lehrende ↔ Entwickelnde
Sicht der Lehrenden | Sicht der Entwickelnden | Beschreibung (Entwickelnden) |
|---|---|---|
Nutzbar | primitive | Das H5P kann aus technischer Sicht nicht abgeschlossen werden. Das bedeutet, diese H5P's können kein XAPI-Event feuern Jedoch kann man es semantisch gesehen abschließen. Beispiele hierfür sind H5P's, die nur aus Text oder Bildern bestehen. |
completable | Das H5P ist abschließbar. Das bedeutet, diese H5P's feuern ein XAPI-Event, sobald sie abgeschlossen sind. | |
Nicht Nutzbar | not usable | H5P ist defekt: - H5P wird nicht angezeigt - H5P kann trotz Aufgabe nicht abgeschlossen werden |
Ungeprüft | not validated | Der Zustand des H5P's ist nicht validiert. |
Zustandsdiagramm
3D-Lernumgebung:
H5P content:
Das sind H5P's die ein XAPI-Event feuern, wenn sie abgeschlossen sind
H5P primitiv:
Diese H5P's können kein XAPI-Event feuern, sind demnach nicht abschließbar.
Beispiele hierfür sind H5P's die nur aus Text oder Bildern bestehen.
State-Pattern in der Implementierung
Auf das State-Pattern wurde explizit verzichtet:
Die Zustände repräsentieren Zustandsdaten, kein kompliziertes Verhalten
Darum brauchen wir in einem Zustand keine Logik
Statt Logik brauchen wir Statusverwaltung
Zustandsänderungen passieren durch einfache Regeln -> Nutzer setzt den Zustand aktiv um
Anmerkung: Vorerst nicht testbar, keine ID vergeben in Writerside Topic