New Plugin Slot for Questions Types

If you need any help in filling out this wiki page, please visit our ILIAS Community FAQ. And please complete the metadata information in the right column after having created the page.

1 Initial Problem

Plugin question types can only be used in ILIAS tests so far. The interface of the plugin slot for test questions is tightly interwoven with base classes from the test and question pool and makes it almost impossible to use such questions in other components without workarounds.

Questions from ILIAS core can be included in learning modules, but only the question editor from Test & Assessment is reused. The presentation of a question is implemented in the learning module, uses deprecated Javascript code and the behavior may differ from the same question in the test. 

The project Introducing Assessment Question Service was hoped to provide a general interface for test questions that could be used in various modules. Due to the stop of this project (see JourFixe-2021-07-12), this possibility was put on hold in favor of a gradual improvement of the code in Test & Assessment.

For developers and users of test question plugins, however, this results in uncertainty as to what effect the gradual changes in the T&A will have on the future usability of their plugins. In addition, no target architecture is yet available towards which to plan and reserve funds. For the maintainers of other ILIAS modules it means in the longer term not being able to use test questions in their modules.

2 Conceptual Summary

This feature request would like to stimulate the conception of a general interface for question types to be used in any modules. Based on many years of experience in Test & Assessment, from the lessons learned in the AQS project, and taking into account the approaches in other systems, a new solution is to be designed, detached from the constraints of gradual refactoring in the T&A.

The solution will initially be designed and implemented as a new plugin slot for general purpose question types. Its interface for using a question in ILIAS modules is to be designed in such a way that it can be fulfilled in the same way by future questions of the ILIAS core. 

The term question interface is used here to represent a bundle of interfaces which are grouped by functional areas. For a conceptional orientation, an "onion model" with different layers is proposed.

• The question core contains all the functions that make up the essence of a question type and which must therefore be implemented differently for the different question types. Additionally the question types can use reusable elements and functions that are provided by the ILIAS core (e.g. kitchen sink elements).
• The question core is decorated by ILIAS in another shell with additional properties and functions. These functions are independent of the question type and can be implemented in ILIAS in general. If there are dependencies to the question type here, they have to be modeled via interfaces to the core. The decoration layer contains properties and functions that are needed for the presentation or correction of a question. The core and the decoration layer together determine what you have to deal with when actually working with a question. The context of a question (learning module, test) will determine which decorations should be available.
• An organization shell takes care of the aspects of using a question in different contexts, e.g. taxonomies and learning goal assignments, or versions and publishing status. It is not neccessary for a how question works but to determine if it can be used in a context and how its result can be further processed.

This model allows the specification to be approached step by step from the inside out. First, the interfaces of the question core are important. In a first version of the plugin slot, it would be sufficient to implement only these interfaces. The core functionality roughly coincides with the functionality that has to be implemented for current plugin question types. Therefore, it should be possible to implement wrapper classes with which the new plugin questions can also be used in the classic T& A without having to change it significantly.

With an optimistic roadmap, a first version of the new plugin slot with the interfaces for the question core could be implemented as a prototype add-on for ILIAS 9. A sample plugin should exploit all possibilities of the slot. In ILIAS 10, the prototype plugin slot would undergo an update and enhancement based on the experience gained. In this state itshould be ready to become part of the ILIAS core. Then existing plugins can be rewritten from the previous plugin slot to the new one. The old plugin slot should be supported in parallel for at least one ILIAS release to give their developers enough time for a refactoring. In parallel the refactoring of ILIAS core question types of ILIAS can be started to use the same interfaces.

This roadmap and the wrapper for the current T&A should make it possible to be free for a new conception without taking the risk of breaking existing functionality of test questions. The new inerfaces can gradually reach maturity before the core questions of ILIAS are refactored.

2.1 List of Affected Views

• Page Editor and Presentation in the Learning Module
• Question Editor and Presentation in T & A

2.2 User Interface Details

The presentation of a test question of the new plugin slot will be done via new components of the UI framework. 

2.3 New User Interface Concepts

When defining the interfaces, the usability in the learning module should be taken into account from the beginning and this also requires offline capability for the HTML exports, provided that the question type allows this (Stack, for example, does not). First thoughts about this were collected in the feature request Offline-Support for Test Questions.

It is conceivable that a canvas is provided by the module which contains the question UI as a child component. The interaction with the question takes place in the question UI. The given answer and the feedback are exchanged between the UI components via Javascript signals with payload. 

2.4 Accessibility Implications

{ If the proposal contains potential accessibility issues that are neither covered by existing UI components nor clarified by guidelines, please list them here. For every potential issue please either propose a solution or write down a short risk assessment about potential fallout if there would be no solution for the issue. }

3 Technical Information

{ The maintainer has to provide necessary technical information, e.g. dependencies on other ILIAS components, necessary modifications in general services/architecture, potential security or performance issues. }

4 Privacy

{ Please list all personal data that will need to be stored or processed to implement this feature. For each date give a short explanation why it is necessary to use that date. }

5 Security

{ Does the feature include any special security relevant changes, e.g. the introducion of new endpoints or other new possible attack vectors. If yes, please explain these implications and include a commitment to deliver a written security concept as part of the feature development. This concept will need an additional approvement by the JourFixe. }

6 Contact

• Author of the Request: Neumann, Fred [fneumann]
• Maintainer: {Please add your name before applying for an initial workshop or a Jour Fixe meeting.}
• Implementation of the feature is done by: {The maintainer must add the name of the implementing developer.}

7 Funding

If you are interest in funding this feature, please add your name and institution to this list.

• …

8 Discussion

9 Implementation

{ The maintainer has to give a description of the final implementation and add screenshots if possible. }

Test Cases

Test cases completed at {date} by {user}

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

Approval

Approved at {date} by {user}.