Integration of the question type ‘Source code’ into 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

The ILIAS core lacks a specialized question type for assessing programming skills in tests and exams. Teachers who want to request and evaluate source code submissions from students must resort to workarounds (e.g., free-text questions without syntax support) or third-party plugins.
The dependence on external solutions for such a fundamental functionality in STEM education leads to disadvantages:
Administrative effort: Plugins must be installed and maintained manually.
Lack of standardization: Availability and functionality are not consistent across all ILIAS installations.
Uncertain future: Long-term compatibility and further development are not guaranteed by the ILIAS core team.Integrating this functionality as a native component would provide a high-quality, low-maintenance, and standardized solution for an important requirement in teaching.

2 Conceptual Summary

The implementation of a native question type for source code submissions in the ILIAS core is proposed. This question type allows you to create assignments in which participants submit their solutions in the form of source code directly in ILIAS.

The core functionalities are:
Code editor in the browser: Participants enter their code in an editor that is displayed directly in the test environment.
Syntax highlighting: The editor supports the most common programming languages and highlights the syntax in color, which makes it easier to read and edit.
Code templates: Instructors can provide a code template (boilerplate) that serves as a starting point for learners to develop their solutions.
Manual evaluation: Submitted code answers are saved for manual evaluation by teachers, including a convenient view with syntax highlighting and copy function.
Inclusion in the core would make this question type a permanent and reliable part of the ILIAS examination system.

2.1 Use Cases

Computer science and engineering: Testing programming skills, algorithms, or data structures in exercises and exams.
Data science & statistics: Submission of scripts (e.g., in Python or R) for data analysis.
Web development: Testing knowledge of HTML, CSS, or JavaScript.
General STEM subjects: Any scenario in which structured code is expected as a solution.

2.2 Details on configuration and procedure

5.1. Configuration (from the creator's perspective)

When creating a new question in the test or question pool object, the following options should be available:

1. Define the question title and task as for other question types.
2. Select programming language: A drop-down list allows you to select the language (e.g., Java, Python, C++, PHP, JavaScript, SQL, R, etc.). The selection activates the appropriate syntax highlighting in the editor.
3. Code template (optional): A text field in which teachers can enter a basic code structure or comments, which is displayed to participants in advance in the editor.
4. Set points for manual evaluation.

5.2. Procedure (from the participant's perspective)

1. The participant opens the test question.
2. The task is displayed within the question together with a code editor.
3. The editor contains the code template, if provided by the teacher. The syntax is highlighted in color according to the selected language.
4. The participant writes or completes the code directly in the editor.
5. After submission, the entered source code is saved as an answer and can be viewed and graded by the grader.

5.3. Procedure (from the grader's perspective)

1. The grader opens the manual grading view for the question.
2. The participant's submitted solution is displayed in a read-only field with the appropriate syntax highlighting.
3. To test the code externally (e.g., in an IDE or on the command line), there is a button that can be used to copy the entire source code to the clipboard.
4.The evaluator enters points and feedback in the appropriate fields and saves the evaluation.

2.3 Mockups

Not currently included. Can be created as needed to visualize the views for participants and evaluators.

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