You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
❌ This issue is not open for contribution. Visit Contributing guidelines to learn about the contributing process and how to find suitable issues.
Overview
Add the Inline Choice question type to the QTI editor. An author writes a passage and inserts dropdowns inline, and each dropdown has its own plain-text options and one correct answer (#5927).
It is the first question type that puts several interactions in one item, and the first placed inside rich text content. The QTI editor core has to learn to carry and score more than one response before the editor itself can be built on top of it.
Scope
Included
Multi-response support in the QTI editor core, and generated response processing that scores an item across all its responses: correct responses divided by total responses.
The inline choice interaction plugin: its descriptor, parsing, XML assembly and validation; the chip node and Insert action in the passage's TipTapEditor; and the editor UI.
Excluded
Scoring strategies other than averaging (weights, all-or-nothing).
Mixing inline choice with other interaction types in one item.
Extensible scoring. How each response contributes to the score comes from its response declaration's capabilities (getScoringRule), with an explicit precedence order. Only correct-response scoring is implemented now. Other rules (e.g. mapping-based) can be added later without changing the core.
Backend. No production change is needed: the server validates against the QTI 3.0 XSD and publishes raw_data as-is. Items with more than one interaction are not Perseus-derivable, so they ship in the QTI package only.
Open question for Kolibri. Kolibri's QTI viewer already renders inline choice and supports every operator the generated response processing uses. How it treats a fractional SCORE (e.g. 0.5) for correctness and mastery still needs to be confirmed with the Kolibri side.
Testing Requirements
Beyond each task's unit tests, the project is done when a channel with an inline choice question (several dropdowns) publishes and renders in Kolibri's QTI viewer, and a partially correct answer produces the expected SCORE.
AI usage
I used Claude Code to draft this tracking issue and its tasks. It read the QTI editor core, the backend QTI validation and publishing path, and Kolibri's QTI viewer to check feasibility. I decided the scope and the split, and reviewed and edited the text.
❌ This issue is not open for contribution. Visit Contributing guidelines to learn about the contributing process and how to find suitable issues.
Overview
Add the Inline Choice question type to the QTI editor. An author writes a passage and inserts dropdowns inline, and each dropdown has its own plain-text options and one correct answer (#5927).
It is the first question type that puts several interactions in one item, and the first placed inside rich text content. The QTI editor core has to learn to carry and score more than one response before the editor itself can be built on top of it.
Scope
Included
TipTapEditor([QTI] Update TipTapEditor to support custom insert node behavior defined on parent component #6176), so the QTI editor can contribute an inline node and an insert action withoutTipTapEditorknowing about QTI.TipTapEditor; and the editor UI.Excluded
Strategy
TipTapEditorseams) and [QTI] Support multiple response declarations per item and generate their response processing #6179 (multiple responses and response processing) can proceed in parallel. [QTI] Inline choice interaction: descriptor, parsing, XML assembly and validation #6180 (descriptor, parsing, validation) depends on [QTI] Support multiple response declarations per item and generate their response processing #6179. [QTI] Inline choice chip and Insert action in the passage editor #6181 (passage chip and Insert) depends on [QTI] Update TipTapEditor to support custom insert node behavior defined on parent component #6176 and [QTI] Inline choice interaction: descriptor, parsing, XML assembly and validation #6180. [QTI] Inline choice interaction editor #6182 (editor UI) depends on all of them. [QTI] Inline choice interaction: descriptor, parsing, XML assembly and validation #6180 and [QTI] Inline choice chip and Insert action in the passage editor #6181 can overlap once the passage markup in [QTI] Inline choice interaction: descriptor, parsing, XML assembly and validation #6180 is agreed.getScoringRule), with an explicit precedence order. Only correct-response scoring is implemented now. Other rules (e.g. mapping-based) can be added later without changing the core.raw_dataas-is. Items with more than one interaction are not Perseus-derivable, so they ship in the QTI package only.SCORE(e.g.0.5) for correctness and mastery still needs to be confirmed with the Kolibri side.Testing Requirements
Beyond each task's unit tests, the project is done when a channel with an inline choice question (several dropdowns) publishes and renders in Kolibri's QTI viewer, and a partially correct answer produces the expected
SCORE.AI usage
I used Claude Code to draft this tracking issue and its tasks. It read the QTI editor core, the backend QTI validation and publishing path, and Kolibri's QTI viewer to check feasibility. I decided the scope and the split, and reviewed and edited the text.