We need to specify the interactions with semantic problems in the generated HTML. For the generated PDF, we already have something of a solution implemented.
Version 1
The content of the sproblem env is printed
The visibility of the solution is subject to the document or didactic context (usually explicitly governed with \startsolutions and \stopsolutions macros in the document. If solutions are allowed,
a. For each of the solution environment we create a button that toggles the visibility of the solution. This to prevent students from peeking and cheating themselves.
b. The button might also include a title/desciption (see #316) of the solution if present
For mcb blocks, we need a a submit button that will generate feedback.
each \mcc should show the choice (probably as radio buttons), uppon submit (if that is enabled; see 3.) the choices are feedbacked using the information provided
Version 2
should specifie based on discussions with the DDI people in the Voll_KI, possibly alread taking the ILIAS facilities in https://studon.fau.de into account. Here are some ideas already.
ad 2a.: For the solution we could generate an input field (of the size specified in the height= attribute and store the contents in local storage keyed by the problem URL. Then the old answer (if it exists) can be shown for continuation.
ad 3. We need a general way of specifying what should happen to submissions and when they are to be checked and feedbacked. I see different scenarios
We need to specify the interactions with semantic problems in the generated HTML. For the generated PDF, we already have something of a solution implemented.
Version 1
sproblemenv is printed\startsolutionsand\stopsolutionsmacros in the document. If solutions are allowed, a. For each of thesolutionenvironment we create a button that toggles the visibility of the solution. This to prevent students from peeking and cheating themselves. b. The button might also include a title/desciption (see #316) of the solution if presentmcbblocks, we need a a submit button that will generate feedback.\mccshould show the choice (probably as radio buttons), uppon submit (if that is enabled; see 3.) the choices are feedbacked using the information providedVersion 2
should specifie based on discussions with the DDI people in the Voll_KI, possibly alread taking the ILIAS facilities in https://studon.fau.de into account. Here are some ideas already.
height=attribute and store the contents in local storage keyed by the problem URL. Then the old answer (if it exists) can be shown for continuation.