Manual evaluation – Improving navigation in the modal dialog (usability during manual correction)

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

When manually grading open-ended test questions (e.g., free text or file upload) in ILIAS, the current workflow for graders is inefficient. To grade the answers of different participants, a grading view (in a modal window) must be opened individually for each person. After entering the evaluation and feedback, this view must be closed in order to then open the view for the next person.
This constant switching between the overview list and the individual assessment modal results in a high number of clicks and interrupts the workflow. It is therefore not possible to correct several submissions in quick succession, which significantly increases the time required for assessment and impairs usability.

2 Conceptual Summary

It is proposed to implement a more efficient assessment workflow that allows users to navigate directly between participants' submissions without having to leave the assessment view. The core idea is to introduce navigation buttons within the assessment modal:
Seamless navigation: Assessors can jump directly to the previous or next submission.
Save and navigate: A combined action allows the current assessment to be saved and the next submission to be accessed immediately in one step.This makes the assessment process a linear and uninterrupted operation, which greatly improves efficiency and user-friendliness.

2.1 Use Cases

Grading free-text questions: Teachers correct a large number of free-text answers. They can quickly jump from one answer to the next without returning to the answer overview.
Grading file uploads: Teachers grade submitted documents (e.g., essays, solutions) in a test. The ability to quickly switch between individual submissions significantly speeds up the correction process.
High number of participants: Especially in scenarios with many participants, the time required for assessment is drastically reduced by avoiding repetitive steps.

2.2 Details about the process

1. The evaluator opens the evaluation overview of a test for a specific question.
2. They click on the first submission to be evaluated. A modal window opens, displaying the person's answer and the evaluation form.
3. At the bottom of the modal window, below the evaluation and feedback fields, there are navigation buttons:
   < Back (or Previous submission)
   > Next (or Next submission)
   Save and Back
   Save and Next
4. After entering the points and feedback, the person clicks Save and Next.
5. The entries are saved and the modal window is updated to display the next person's submission in the list. The evaluator can immediately begin the next correction.
6. Alternatively, the person can scroll through the submissions using Next or Back to get an overview without having to save immediately.
7. This process continues until all submissions have been evaluated. The modal must only be closed at the end of the entire process.

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

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