Feature Wiki

Information about planned and released features

Tabs

Revise KPrim 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 answer 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 creation of a KPrim answer form will be split into two steps, to improve readability and understandability:
    • The form to set up the answer form will offer a maximum of  two sections.
      • A first one related to marking, if the question is used in a context where marking is required, containing
        • a required numeric inputs to enter the awailable points,
        • and a checkbox to enable half-point marking
      • and a second one related to the view containing
        • a required switchable group input to select the option labels,
        • a checkbox to enable shuffling of answer options,
        • a required numeric input to set the image size preset to 150 (hard coded).
    • The form to add answers, displayed in the next step of the form, will offer an input to add a text for the option allowing for markdown and an input to add one single image. At least one of the two needs to contain information. It will not be possible to change the order of answer options on this view. If the answer form is used in a context where marking is required, an additional select input will be offered to define if the participant must select the left / positive or right / negative value.
    • The nomenclature for KPrim answer forms is complicated as there are different answers each containing two options, a positive and a negative one. To avoid using "options" on to separate levels and so to create  confusion and differently from e.g. the other multiple choice types, the answers will be called "answers" not "answer options" and the "answer options" are the two different values that can be selected per answer.
  • The feedback options are simplified by removing the option to set a "Mode of answer specific feedback" as the meaning of the different settings is rather obscure and hard to understand. Feedback will always be shown for all answers. It could be envisoned, to add an option to display a different feedback depending on the response being equal to the best response, but we would suggest to not do this currently and leave it for a next iteration to reduce complexity and lilberate some working time to address more pressing issues.

3 User Interface Modifications

3.1 List of Affected Views

  • All views of `assKprimChoiceGUI`

3.2 User Interface Details

The Basic Answer Form Properties of the KPrim answer form are slightly simplified, they show two sections. A first one labeled "Marking", only shown if the context requires marking, containing an input to add points and one to enable awarding half points. A second section labeled "View" contains an input to change the label for the options that need to be selected by participants, one to shuffle the options, and one to set the image size.
The inputs to enter the answers are split out to their own form step. Each of them contains a markdown input to add a text and another input to add an image. Exactly one image can be added. At least one of the two inputs must be provided otherwise the form is invalid. An additional select input to chose the option that must be selected by the participant for the answer to be correct is provided if the context the answer form is used in requires marking.
The overview page follows the standard for all questions. The information on marking and the columns for the left / positive - right / negative values are only shown if the context requires marking.

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

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.1 Involved Authorities

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

4.2 Technical Aspects

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:  {Please add related profile link of this person}

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

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: 22. Jun 2026, 09:25, Kergomard, Stephan [skergomard]