Integration of the “Auditing for test questions” function into the ILIAS core

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

In certain test scenarios, especially language tests (e.g., listening comprehension), it is necessary to integrate audio or video files directly into test questions. Standard ILIAS tests do not offer integrated functionality to:
 - Assign audio/video files directly to a question.
 - Limit the maximum number of playbacks per user and test run.
 - Prevent the user from pausing playback in order to ensure standardized test conditions.

These limitations make it difficult to conduct such tests efficiently and often require workarounds or additional supervision.
Translated with DeepL.com (free version)

2 Conceptual Summary

It is proposed that the functionality described in the original feature wiki entry “Auding for Test Questions” be integrated into ILIAS Core.
This concept was originally developed by Databay AG on behalf of the University of Göttingen and addresses the above-mentioned problems.

The core idea is:
 - Media assignment: Teachers can upload and assign an audio or video file to each test question.
 - Playback control:
    - Limited playback: The maximum number of playback attempts can be set per question (0 = unlimited).
    - Pause control: It can be configured whether users are allowed to pause playback or whether playback is forced.    
  - Output in the test: Participants see a player in the question. When the maximum number of repetitions is reached, the player is replaced by a corresponding message.

The integration of this concept would extend the functionality of ILIAS tests and directly support specific requirements, especially in the area of language exams.
Translated with DeepL.com (free version)

2.1 Use cases

Language exams: Conducting listening comprehension tasks in which students play the audio text independently (e.g., a maximum of two times).
Other test scenarios: All tests in which audio-visual stimuli must be presented under controlled conditions (limited playback, no pause) (e.g., in psychology, sports science).

2.2 Details on configuration and procedure (based on original concept)

5.1. Configuration (from the teacher's perspective)
When editing a question in a test or question pool object, the following additional options should be available:
Enable auding: A checkbox to enable/disable the auding functionality for this question.
Auding file: A file upload field for uploading the desired audio or video file.
Auding mode: A selection option (e.g., radio buttons):
- Force playback (pausing not allowed)
 - Pausing allowed
Number of repetitions: A numeric field for entering the maximum number of playbacks allowed. The value 0 means unlimited repetitions.

5.2. Procedure (from the participant's perspective)
The participant opens a test question for which Auding is activated.

1. The participant opens a test question for which Auding is activated.
2. An audio/video player is displayed within the question.
3. The participant starts playback using the player controls.
4. Case 1 (pausing allowed): The participant can pause and resume playback using the player controls.
5. Case 2 (pausing not allowed): Once started, playback continues until the end; the pause function is disabled.
6. After playback has ended, the participant can start playback again, provided that the maximum number of repetitions has not yet been reached.
7. If the maximum number has been reached, the player is no longer displayed or is replaced by a message (e.g., “No further playbacks allowed.”)

2.3 Mockup

Not currently included. Can be created if required.

3 User Interface Modifications

3.1 List of Affected Views

3.2 User Interface Details

{ For each of these views please list all user interface elements that should be modified, added or removed. Please provide the textual appearance of the UI elements and their interactive behaviour. }

3.3 New User Interface Concepts

{ If the proposal introduces any completely new user interface elements, you might consult UI Kitchen Sink in order to find the necessary information to propose new UI-Concepts. Note that any maintainer might gladly assist you with this. }

3.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. }

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

{ Necessary technical information have to be provided here, e.g. dependencies on other ILIAS components, necessary modifications in general services/architecture, potential security or performance issues. }

4.3 Privacy

{ Personal data that will need to be stored or processed to implement this feature have to be listed here. For each date give a short explanation why it is necessary to use that date. }

4.4 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. }

4.5 Contact

Person to be contacted in case of questions about the feature or for funding offers:  Holger Markus holger.markus@uni-goettingen.de, Andreas Zahn andreas.zahn@uni-goettingen.de

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}

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}.