Generalize Quiz

[SilasBerger]

Right now, the Quiz and the ChoiceAnswer components are tightly coupled: The Quiz even lives in the ChoiceAnswer namespace. If we are going to use this feature in an exam, it will most likely look as follows:

# Exam
:::aufgabe[Question 1]
Describe the difference between data and information it at most 3 sentences.

<QuillV2 id="…" />
:::

:::aufgabe[Question 2]
Decide whether the following claims are true or false.

<Quiz id="…">
  <TrueFalseAnswer>…</TrueFalseAnswer>
  <TrueFalseAnswer>…</TrueFalseAnswer>
  <TrueFalseAnswer>…</TrueFalseAnswer>
  <TrueFalseAnswer>…</TrueFalseAnswer>
</Quiz>
:::

:::aufgabe[Question 3]
<ChoiceAnswer multiple id="…">
  > Select all that apply.

  1. Foo
  2. Bar
  3. Baz
  4. Blub
  5. Bla
</ChoiceAnswer>
:::

This is okay, but has the following limitations:

• Question order randomization only works within an individual quiz (in this example: the individual TrueFalseAnswers inside question 2).
• Even with after-the-fact solution provisioning (upload via some solution file, or adding the correct={[…]} props to the markdown file after the exam), there is no global points count across the entire exam, only within the individual quizzes.

Therefore, it might make sense to disjoin the two concepts <Quiz> and <ChoiceAnswer> (including <TrueFalseAnswer> and potential future special cases, implicitly included here and in the following), under the following limitations / conditions:

• The ChoiceAnswer is still allowed to know whether it lives inside a quiz, since it has to change its behaviour depending on its context.
• The <Quiz> still tracks the answer to all <ChoiceAnswers> and persists them as part of a single document, even though that leaves the <ChoiceAnswer> with a special standing inside a <Quiz> (since there will then be other question types that are tracked in individual documents).
• The <Quiz> is still allowed to carry certain props that only apply to <ChoiceAnswers> (or potential future auto-assessable question types), such as scoring={...}.

This change would allow us to rethink the use of the <Quiz> component as a unified exam container as follows:

# Exam
<Quiz id="…">
  ## Question 1
  <Feedbackable>
    Describe the difference between data and information it at most 3 sentences.

    <QuillV2 id="…" />
  </Feedbackable>

  ## Question 2
  <QuestionGroup>
    Decide whether the following claims are true or false.

    <TrueFalseAnswer>…</TrueFalseAnswer>
    <TrueFalseAnswer>…</TrueFalseAnswer>
    <TrueFalseAnswer>…</TrueFalseAnswer>
    <TrueFalseAnswer>…</TrueFalseAnswer>
  <QuestionGroup>

  ## Question 3
  <ChoiceAnswer multiple>
    > Select all that apply.
  
    1. Foo
    2. Bar
    3. Baz
    4. Blub
    5. Bla
  </ChoiceAnswer>
</Quiz>

The idea behind the <QuestionGroup> relates to the question order randomization and is intended to ensure that everything belonging to - in this case - question 2 is moved as a hole. The downside of this approach is that the order of its contents (the individual True/False questions) won't be randomized anymore, so maybe there's a better solution here.

On of the key concepts that this new approach allows is the introduction of some kind of <Feedbackable> component. To the student, this component simply displays its children. To the teacher, it also displays a and a points input, so that they can manually score these types of questions and leave a written feedback where necessary.

The big open question is where that feedback would go. One approach would be to extend the "assessment" concept to also include a feedback: string field. This would be relatively easy to implement and it would allow the Quiz to include the manual scoring in its total score calculation, removing the need for any manual points counting. The downside is that, in the current implementation, the assessment is derived from the (persisted) choices + the correct arrays + the scoring function (if available), so it is itself not persisted.

A potential solution to this problem could be to use a file-system approach where teachers upload a grading file (potentially useful anyway, since that would allow them to provide the <ChoiceAnswer> questions with the correct information only locally, during grading), and to then write the feedback and manual scores back to that file. Students wouldn't have access to that feedback, but this might not be a problem, since we could simply generate a PDF report file with as much or as little information as the teacher wants to include, and give that back, instead of the original exam with the assessment and feedback added to it.

Another option could be to instead introduce a new Feedback document type and let the Feedbackable have its own ID. That document could be persisted on behalf of the student being graded, and teachers could use the permission system to decide at what point (if at all, see argument about the PDF report) a student is allowed to read that document. Downside here is that the Quiu would have to be made aware of that document type as well, and consider both the ChoiceAnswer document and the Feedback document in the calculation of its final score, the generation of a potential PDF report, etc.