Option for failed attempt in ILIAS Test

1 Initial Problem

Currently, a test participant has not the option to remove all answers from an open test. It is only possible to go from one question to the next or the previous question and use the Actions to "Undo Editing" (in not saved questions) or "Delete Answers". 

Some examination regulations do require this opportunity to fail an attempt wholesome.

We propose to add this option, to avoid problem in the use of the ILIAS T&A for E-Exams.

Alternative 2

In the context of an examination, candidates have the right not to have their examination marked, or to have it marked with 5.0, even though they have answered questions. In this case, a paper examination could be crossed out or torn up.  A function "delete all entries" or "do not hand in exam" is therefore required in the test object.

2 Conceptual Summary

We want to add another setting in the general tab to activate the failed attempt option. The setting is not activated by default:

Byline:
Another button, 'Submit failed attempt' is shown in the toolbar. This button triggers a modal, with allows the participant to delete all previously entered answers and finish the test attempt. This action by the participant is logged.

After activating the option, a new button 'Submit failed attempt' is shown besides the 'Finish Test' button. This button will trigger an interruptive modal, which allows the participant to delete all answers in this test run. 

The 'Failed Attempt' interruptive modal will ask, if one is sure about that and delete all entered answers after confirmation and finish the test run. If the number of passes is limited, the participant is warned about this fact.
 

Mockup

Wording Suggestions

Title: Failed Attempt
Warning Message: You are going to delete all your entered answers and finish this rest run. Do you really want this?
Buttons: "Yes, I want to delete all my answers" / No, go back to the previous question"

Title: Failed Attempt
Warning Message: You are going to delete all your entered answers and finish this rest run. You reach the maximum number of allowed test passes. Do you really want this?
Buttons: "Yes, I want to delete all my answers" / No, go back to the previous question"

With the introduction of this modal, we also need to streamline the behavior of the 'Finish Test' button. It must also trigger an interruptive modal in all cases. This would also implement a previous JourFixe decision.

Mockups

Wording Suggestions

Title: Finish test pass
Warning Message: You are going to finish this test. You won't be able to enter this test pass again to change your answers. Do you really want this?
Buttons: "Yes, I want to finish this test pass" / No, go back to the previous question"

Title: Finish Test
Warning Message: You are going to finish this test and reach the maximum number of allowed test passes. You won't be able to enter this again to change your answers. Do you really want to finish the test?
Buttons: "Yes, I want to finish the test" / No, go back to the previous question"

Alternative 2

We would like to expand the submission workflow at the end of an exam so that the participants are finally asked whether they would like to "submit the exam" or "do not grade the exam".

3 User Interface Modifications

3.1 List of Affected Views

Alternative 2

• The function should be optional. It is thus an option in the test object that can be switched on or off. An option is added to the test settings with which the failed test function can be switched on.
• The last view of the "End Test" before confirming the submission.  [Note: This view is only visible if the number of test runs has been limited to 1 in the test object setting].

3.2 User Interface Details

Alternative 2

• The previously mentioned affected view should be extended to include another button for a function that deletes all answers given in the test and submits a completely blank test.

• After a user chooses the option to submit a blank test and, thus, erase all his answers he should get a chance to rethink his actions or verify that it was not an accident. The user then reads a warning describing the consequences of his action and confirms that the user accepts the conditions and is aware of the consequences. Finally, he is then able to confirm his action.

You can try this mockups and click on the button under: https://testpenpot.rz.uni-freiburg.de/#/view/4ca84a5e-9f40-805a-8001-913d3ee5c76a?page-id=c54cb784-fa04-80a4-8002-bcda951aeffc§ion=interactions&index=0&share-id=9c640b85-5928-80af-8002-bcf759794614 

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

5 Privacy

• The data of the test processing is recorded in the log and remains in the system for the ILIAS administrators.

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

7 Contact

• Author of the Request: Strassner, Denis [dstrassner] Alternative 2: Slotosch, Sven [sven.slotosch]
• 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.}

8 Funding

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

• bwILIAS
• Uni Freiburg

9 Discussion

We have developed an alternative proposal in parallel as a work package of the bwILIAS project. This is integrated here in the feature article and marked as "Alternative 2".

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

Privacy

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

Approval

Approved at {date} by {user}.