Fill-in Feedback, Localizations, and Static Representation

4 views
Skip to first unread message

D. Brian Walton

unread,
Jul 12, 2024, 5:40:00 PM (11 days ago) Jul 12
to pretext-dev
I'm working to finish the documentation of the Fill-in-the-Blank component and have realized I need to address the connection between the feedback and static representations.

The original implementation (fillin-basic) creates a #solution that first *restates* the original question, replacing the fill-in blanks with the corresponding _answer_, and then adds on the feedback that is given if a user provides that answer. I suppose this makes sense if the "feedback" is closer to a statement explaining the reasoning that the answer is correct. It does not make sense for feedback on the order of "Correct".

However, in the dynamic representation (html/web), when a user submits a correct response to one question and not to another, feedback that does not explicitly state "Correct" or "Incorrect" but gives a sentence of reasoning may be confusing the user if they can't tell if the feedback is telling them to change their answer or affirming the reasoning.

In Tacoma, one observation was the challenge of consistency in feedback. The localizations file has entries for "correct" and "incorrect". I'm wondering if perhaps the Runestone Component itself should be informed of the localization strings for correct/incorrect and insert that prior to the provided feedback text rather than have it encoded in the #feedback. This would allow the static version to skip the "Correct!" when presenting the generated solution. And then the #feedback would *only* include explanatory feedback.

Does this make sense as a strategy?

Brian

Andrew Scholer

unread,
Jul 13, 2024, 3:14:00 PM (10 days ago) Jul 13
to prete...@googlegroups.com
If I understand you correctly, Correct/Incorrect would only be used in the dynamic version of the response? 

In that case, it seems to make sense for Runestone to be responsible for constructing the feedback message presented in the interactive context. If there are hardcoded strings that will need localizing as a part of doing so, they should be a part of the Runestone js. It has provisions for string localization.

Andrew Scholer (he/him/his)
Computer Science Instructor/Program Chair
Chemeketa Community College


--
You received this message because you are subscribed to the Google Groups "PreTeXt development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pretext-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pretext-dev/CAH7VRo%2ByZ0OyJtQ8n%2BV6rSd0jZ%2BAzP7sdLqYHbuFNrQKTSCbpA%40mail.gmail.com.

D. Brian Walton

unread,
Jul 13, 2024, 3:27:16 PM (10 days ago) Jul 13
to prete...@googlegroups.com
Andrew,

Thanks for the response.

Yes. Currently, there is a single feedback string that is used for both the interactive, web-based questions and also for the static representation generated solutions (LaTeX, Braille, etc.). Including "Correct/Incorrect" doesn't make sense for the static versions.

On the second point, the problems are associated with the language of the corresponding PreTeXt book, not the Runestone service. This is why I'm thinking it would be good for the problem to include the information to send to Runestone for the extra wording.

Alternatively, I don't know if there could be a different visual representation of correct/incorrect for individual blanks on the fill-in and not worry about including extra wording with the feedback. I'm still trying to think through how to insert "Correct/Incorrect" when the feedback could actual be structured with paragraphs or unstructured text. (Maybe it should require structure and then put the Correct/incorrect in a leading <p>?)

Brian

Reply all
Reply to author
Forward
0 new messages