Feature Wiki

Information about planned and released features

Tabs

Revise Error Text Question Creation Process

Page Overview

[Hide]

This feature request is part of (Project) Revision of Test Question Creation.

1 Initial Problem

The set of questions available has grown organically over many years. There are redundancies and inconsistencies and the forms to edit the questions are based on a lot of custom code based on the legacy forms featuring many unique concepts, like forms that are rendered by javascript on the client.

There is a clear need to bring this process back in alignment with the current way of doing things in ILIAS, to remove redundancies, and rectify inconsistencies.

2 Conceptual Summary

  • This Feature Request follows the guidelines set by Revision of ILIAS Test Question Creation Process and fleshed out for the anwser form type "Cloze" in Revise Cloze, Long Menu, Numeric, and Text Subset Question Creation Process.
  • This request is only concerned with question creation and structure. The form to answer a question will basically stay as is and only undergo some minor tweaks.
  • The form to set up the answer form will offer a maximum of two inputs. A required input "Error Text" of the type textarea and, if marking is required in the current context, a required numeric input expecting a positive value for the points that will be subtracted from the mark, if a wrong word is selected.  It will not be possible anymore to set the text size.
  • It is proposed to only have one type of marker to flag words and group of words that award points when selected. This would thoroughly simplify parsing and minimize the probability of interactions with markdown syntax. We would suggest to keep the double brackets as markers. Current texts marked with the pound character will be migrated.
  • If marking is required a second form will be shown, displaying a section for each of the marked words/group of words containing a required text input for the correct replacement and, if marking is required in the current context, a required numeric input to enter the points awarded for its correct selection. It will not be possible anymore, to leave the correct replacement empty as it is today. This currently leads to issues when displaying the best solutions, as either the position of the word/word group becomes invisible or we need to add some fortuitous content.
  • The feedback options are simplified by removing the option to define a feedback per answer. It is not clear when this feedback should actually be shown and it is doubtful that it is useful. It could be envisoned, to allow to add a feedback per word in the text and each defined word group, but we would suggest to not do this currently and leave it for a next iteration to reduce complexity and liberate some working time to address more pressing issues.

3 User Interface Modifications

3.1 List of Affected Views

  • All views of `assErrorTextGUI`

3.2 User Interface Details

The first form step when creating an error text question. It shows two fields, one textarea for the text itself and an input for the points that are subtracted for wrongly selected words.
The second step is only shown, if the context requires marking. It show a section per selection awarding points containing a required text input to add a correct text and a required numeric input to enter the points awarded when it is selected.
The initial view for editing a question shows a panel for the basic answer form properties showing the error text and depending on the context the amount of points that will be subtracted on wrong selections. Below it a data table shows the list of errors, with the correct text and the available points. The table offers a standard action to edit either a single or multiple errors.

3.3 New User Interface Concepts

None

3.4 Accessibility Implications

The forms to create questions are based on legacy-ui-forms with a lot of custom inputs that have a huge amount of accessibility issues. By moving these forms to KS-Forms a lot of the issues should be resolved. Additionally it will be easier to address future accessibility issue.

4 Additional Information

4.1 Involved Authorities

If this request is related to multiple components, please list both authorities for all related components.

4.2 Technical Aspects

  • In the current implementation data is stored redundantly, once as a raw text, once as a parsed text, and finally once in the form of a list of marked errors. This leads to problems in keeping data aligned. We suggest to move to a single way of storing in spliting the whole text into a list of words and storing them separately. The position in the text will need to be stored separately and words that belong will need to be flagged as belonging to a group that then starts with the first flagged word and ends with the last one. We will basically does treat every word as an answer option and the text as a multi select.
  • Additional technical aspects of this request are provided as part of the project. See: (Project) Revision of Test Question Creation .

4.3 Privacy

This feature request doesn't change the data that is collected and also doesn't change how it is presented. It clarifies the storage of answers by users answering questions, by doing so it will improve the understandability and the structure of the data thus making it easier to control the data's lifecycle.

4.4 Security

By moving to KS-Forms and restructuring and clarify the storage of data, the data will be easier to control and user inputs in the KS-Forms will be more consistently validated and sanitized on output.

4.5 Contact

Person to be contacted in case of questions about the feature or for funding offers: Strassner, Denis [dstrassner]

4.6 Funding

Funding status and funding parties are listed in the block 'Status of Feature' in the right column of this page.

If you are interested to give funding for this feature, please get into contact with the person mentioned above as 'Contact'.

5 Discussion

Nishino, Kenji [kentoni]: Thank you very much for this suggestion. The ‘Error Text’ question type certainly needs revising. My main concern with this question type has always been the marking scheme, as it is currently the only question type that requires negative marking. I would therefore welcome the opportunity to revisit the issue of its implementation within the SIG-EA. One possible option, for example, would be to allow only a limited number of words or terms to be highlighted.

6 Implementation

Feature has been implemented by {Please add related profile link of this person}

6.1 Description and Screenshots

{ Description of the final implementation and screenshots if possible. }

6.2 Test Cases

Test cases completed at {date} by {user}

  • {Test case number linked to Testrail} : {test case title}

6.3 Privacy

Information in privacy.md of component: updated at {date} by {user} | no change required

6.4 Approval

Approved at {date} by {user}.

Full Screen

Last edited: 11. Aug 2026, 09:34, Strassner, Denis [dstrassner]