Option for Delete all Answers in ILIAS Test

1 Initial Problem

Currently, a test participant has not the option to remove all answers from a running 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 Answer".

Some examination regulations do require this opportunity to fail an attempt wholesome. Therefore we propose to add this option, to avoid problem in the use of the ILIAS T&A for E-Exams.

2 Conceptual Summary

The 'Overview of Answers Given' gets an optional button to 'Delete all submitted answers'. This button can be activated at the settings of the Test. When using this function, all answers which were submitted are deleted and marked as 'unedited'. This action is irrevocable.

The button triggers a modal, with allows the participant to delete all previously entered answers of the test run and finish the test attempt. This action by the participant is logged. The 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.
 

Within this Feature Request, the 'Overview of Answers Given' is moved to Kitchen Sink (details below).

3 User Interface Modifications

3.1 List of Affected Views

3.2 User Interface Details

3.2.1 General Settings - section 'Finishing the Test'

3.2.2 'Overview of Answers Given'

For this view, the screen from the 'Detailed Results' is adapted. Alle Questions are expanded from the beginning. Only the following information are shown:

At the toolbar three buttons are located. There is one new button added:

'Overview of Answers Given' in ILIAS 10

3.2.3 'Failed Attempt' interruptive modal [new]

Like the modal to Finish the Test, the button "Delete all Answers" will trigger a modal with a slightly different wording.

After confirming the deletion of all answers and ending of the test, the test attempt is ended and no points are given, because no answers were submitted.

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: Lowe, Simon [simon.lowe]

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

Old version of this Feature Request

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.

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

User Interface Modifications

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

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 

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

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

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

Privacy

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

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

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

Funding

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

• bwILIAS
• Uni Freiburg

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

Strassner, Denis [dstrassner], 04 OCT 2023:

As a maintainer, I don't currently see the idea as making sense overall. Neither my original idea postulated in the FR, nor your alternative. I will not add another option to the confirmation dialog in the modal for ending tests. 
Therefore, I am not scheduling a feature workshop for this either.
Special requirements, which are related to specific regulations of institutions, but only affect a minority, should better be implemented in solutions like patches or plug-ins, which are especially made and maintained for these institutions. Not least for such special requirements, the TB has appointed the "extensibility" of ILIAS as one of the core points of their strategy.

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