Introduce interruptive modals in the Competence Management

1 Initial Problem

Our competence management users regularly report that they have problems dealing with the competence management since it's not really clear when a competence is dealt with. One example is the following: Users walk through a diagnostic test which links questions to (e.g.) 4 competences. Upon completion of the test users may or may not end up in the "competence results" subtab an see the competences used once. The next time they want to know something about competences they have to navigate to "achievements"->"competences" and so on. This problem gets even worse when dealing with e.g. learning modules in which the learning progress produces a competence result. Upon completion of the learning module the user does not understand that he/she got a competence level assigned.

In order to make the use of competences clearer for the enduser we would like to introduce something similar to the "Badges" which is shown everytime a competence record is generated (and maybe what profile it belongs to). To achieve this we could use interruptive modals (see below). This would reduce the problems that the feature "Present Competence Records once they are generated" (https://docu.ilias.de/goto.php?target=wiki_1357_Present_Competence_Records_once_they_are_generated) tried to solve which unfortunately doesn't fully solve the issue it addresses.

2 Conceptual Summary

We dream of a a huge modal that shows up after a competence is written. This could e.g. be after finishing a test or after the next login process when a tutor set a competence level. In order to to this we would like to use an interruptive modal which makes the competence oriented end user clear that he/she actively interacts with competences.

2.1 General Goal

We want the modals to behave like handlers. As soon as a competence entry is written the handler should be activated and show the modal as soon as the corresponding object finishes.

2.2 Objects writing competences

E.g. Learning Module: Option 1: Show the modal as soon as the learning module is closed AFTER the competence entry/entries is/are written. Option 2: Show the modal DURING the learning module as soon as the competence entry is written. This will probably have to be defined on a per object basis.

New Stuff:

3 User Interface Modifications

3.1 List of Affected Views

• The modal is supposed to pop up as soon as a competence entry is written

3.2 User Interface Details

• No new interface shall be introduced. We will use one of the modals from the kitchen sink.

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

{ Please list all personal data that will need to be stored or processed to implement this feature. For each date give a short explanation why it is necessary to use that date. }

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: Falkenstein, Rob [rob]
• 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.

• Uni Freiburg

9 Discussion

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}

Approval

Approved at {date} by {user}.