Quiz-Endpoints

[sheepyhollow]

Es sollte zwei Quiz-Endpoints geben

1. quizdata: Liefert die im Quiz verfügbaren Tags (und ggf. ein paar Metadaten wie z.B. Anzahl aller Fragen)
2. quizsession: nimmt Parameter entgegen und liefert das entsprechende Paket mit Fragen und Antworten in zufälliger Sortiertung

(Die Namen sind nur Vorschläge, es mag bessere Ideen geben, z.B. quizinfo, quizmeta oder einfach nur quiz o.ä. Ich fände ja quizmaster ziemlich witzig...)

Parmeter für eine Quizsession:

• Fragenanzahl
• Difficulty (als range?)
• Tags
• ...?

[sheepyhollow]

@kerstinhartmann die drei o.g. Parameter sind eigentlich alle, die sinnvoll sind, oder?

Defaultwerte wären dann

• count: 10
• difficulty: "alle"
• tags: "alle"

[kerstinhartmann]

ja, die 3 sind erstmal alles was wir brauchen.

Mir ist gerade noch folgende Idee gekommen: Ich könnte mir noch ganz gut vorstellen sowas wie "unbearbeitete Quizfragen" oder "falsch beantwortete Quizfragen" anzubieten, aber dafür müssen wir dokumentieren, welche Quizfragen bereits bearbeitet wurden und ob richtig/falsch. Das ginge von der Datenerfassung her vermutlich in die gleiche Richtung die Schwierigkeitsgrade analytisch zu bestimmen.. Nichts was wir jetzt brauchen, aber die Idee wollte ich zumindest notiert haben.

[sheepyhollow]

Von Planty kam die Frage nach Custom Text (die wollen Anrede "Sie", wir nutzen sonst "Du"). Das Quiz ist afaik die einzige Komponente, in der das vorkommt. Wir könnten den Content-Creators die Möglichkeit geben, eigene Intro-Texte für das Quiz zu erlauben. Wir können aber auch im Frontend eine App-spezifische Lösung suchen.

[chgad]

Note to self: Alle Tags des Quizes bekommt man durch TaggedQuiz.tags_for(QuizQuestion)

[chgad]

quizdata: Liefert die im Quiz verfügbaren Tags (und ggf. ein paar Metadaten wie z.B. Anzahl aller Fragen)

Was denn genau für Metadaten jetzt?

[chgad]

Eine weitere Frage ist: Wie geht man mit der Angabe mehrerer Tags um?

Bsp. wir geben tags=A, B, C an. Sollen dann nur Fragen ausgewählt werden die Alle drei Tags besitzen, die NUR diese Tags besitzen oder welche die mindestens EINES der Tags Besitzen?

[sheepyhollow]

Was denn genau für Metadaten jetzt?

Es müssen alle Informationen da sein, die das Frontend braucht, um einen sinnvollen Request zu stellen. Die einzige "interessante", aber funktional evtl. nicht notwendige Info wäre die Anzahl aller verfügbaren Fragen (die könnte man im Startbildschirm anzeigen).

Wie ist das denn aus, wenn ich eine Session mit "unmöglichen" Parametern anfrage? Beispiel: Es gibt das Tag "Karbonate". Ich schränke meine Anfrage auf 10 Fragen ein, es gibt aber nur 5 passende Fragen.

Muss das Frontend wissen, dass es max. 5 anfragen darf (das wäre so ein Metadatum) oder werden einfach nur 5 ausgegeben?

[sheepyhollow]

Eine weitere Frage ist: Wie geht man mit der Angabe mehrerer Tags um?

Ich würde das als OR lesen, also mindestens eines der Tags. Das ergibt vom Spielmodus her am meisten Sinn: Gib mir Fragen aus den Themengebieten A, B und C.

[chgad]

Wie ist das denn aus, wenn ich eine Session mit "unmöglichen" Parametern anfrage? Beispiel: Es gibt das Tag "Karbonate". Ich schränke meine Anfrage auf 10 Fragen ein, es gibt aber nur 5 passende Fragen.

Muss das Frontend wissen, dass es max. 5 anfragen darf (das wäre so ein Metadatum) oder werden einfach nur 5 ausgegeben?

kommt drauf an wie wir das handhaben wollen

[chgad]

Muss das Frontend wissen, dass es max. 5 anfragen darf (das wäre so ein Metadatum) oder werden einfach nur 5 ausgegeben?

Naja das können wir schwer alles im vorhinein ausgeben "Wieviele Fragen gibt es zu jeder Tagkombination"

[sheepyhollow]

Mir fallen mehrere Sachen ein:

1. Die "Metadaten" enthalten diese Informationen, z.B. in der Form

   { "tag": "Karbonate", "number_of_questions": "5" }

   Dann können wir auch beim Wählen der Parameter angeben, wie viele Fragen übrig bleiben. Dann sind wir aber schon wieder am Sortieren und Filtern im Frontend - und das Backend muss immer diese Info zusammenstellen, das kostet auch Zeit.

2. Wir überlegen möglichst schlaue Reaktion auf Sonderfälle, wie z.B. einfach Ignorieren der Gesamtzahl, wenn es nicht genug Fragen gibt. Also wir geben Parameter an und das Backend "macht was Schönes draus". Schwierig sind dann Edge-cases, an die wir nicht gedacht haben

3. Eine Fehlermeldung, die das Frontend prozessiert. Das ist ggf. für Benutzer aber nervig, wenn man mehrere Versuche machen muss bis es klappt.

[chgad]

Ich würde folgendes machen und das sollte alles abfangen:

1. Wählt der Nutzer eine Kombination aus, sodass KEINE Fragen zurück kommen ---> "Ooops in dieser Kombination gibt es keine Fragen, versuche eine andere Kombination." kann man über Länge des Response Objektes === 0 abfangen 2, Wählt ein nutzer eine Kombination aus in der WENIGER Fragen Vorhanden sind als man angefragt hat. "In dieser Kombination gibt es nur, N Fragen, Viel Erfolg!"

Was schlimmeres kann nicht passieren.

Aber du schweifst von meiner Frage ab. Welche Metadaten braucht das Frotnend über das Quiz? Ich habe jetzt tags, difficultiesund count(Kann man dem User ja mal anzeigen, just for fun)

[chgad]

Eine Fehlermeldung, die das Frontend prozessiert. Das ist ggf. für Benutzer aber nervig, wenn man mehrere Versuche machen muss bis es klappt.

Tja mit Großer Individualisierung, kommt große Verantwortung

[sheepyhollow]

Dein Vorschlag ist gut! So kann es gemacht werden. Denn es geht ja nur um die Fragenanzahl. Und idealerweise sind die Quizzes so groß, dass man immer genug Fragen findet hust

Und mehr als tags, difficulties und count fällt mir in der Tat nicht ein. Der type sollte egal sein, ein bisschen spannend soll es ja bleiben - und sonst gibt es keine Eigenschaften.

[chgad]

Gut dann kopier meinen Vorschlag mal in Frontend rüber und ich kann heute das Quiz hoffentlich abschließen.

[sheepyhollow]

Und die "Anleitung", wie die Anfrage zu machen ist, ergibt sich aus swagger?

[sheepyhollow]

Ich fürchte, die Tags fehlen noch in der Ausgabe der /quizsession 😬 Sie sind auch in /quizquestions nicht mehr enthalten.

[chgad]

Ich dachte wir brauchen die nicht mehr ausgeben?

[sheepyhollow]

Hm - doch, eigentlich schon. Wir zeigen das Tag/Thema in der Frage an, sogar als Überschrift (das werden wir noch etwas anpassen, aber es soll schon sichtbar sein).

[chgad]

Alles klar, dann kommt das wieder rein.

[sheepyhollow]

Kerstin hat darauf hingewiesen, dass der Range-Antworttyp keine Einheiten kennt. Das kann bis auf Weiteres in der Frage entsprechend abgefangen werden, aber ein optionaler Einheiten-String wäre noch eine gute Ergänzung. Eigenes Issue (wer auch immer das bearbeitet 😉 )?

[chgad]

Eigenes Issue