Show Advanced KnowledgeHide Advanced Knowledge

Test Player « Self-Assessment »

This feature request is part of the project Splitting-up T&A Into New Components.

1 Initial Problem

There are different test and assessment scenarios with different settings and options to choose from. To reduce complexity for the authors of tests, the variety of settings and options should be limited to those which are really needed for a special scenario. This request is intended to draw attention on the scenario self-assessment. This scenario is very important to promote learning processes. It is especially used for practicing skills and knowledge and giving learners instant feedback on their current level of skills and knowledge, often in combination with instructions of how to proceed and what might be the next learning steps (for example links to learning materials, tips on skills or themes which should be deepened or repeated). It is a scenario which differs in many ways from scenarios like E-Exams and therefore needs a special test player.

2 Conceptual Summary

The requirements for the test player “Self-Assessment” were discussed in the working group Splitting up Test & Assessment.

For all test players it could be useful to distinguish between standard settings and optional settings which could be intentionally chosen by authors.  Some of these standard and optional settings shall be pointed out here:

• In most cases, self-assessment is an anonymous test (= standard setting); but there could also be contexts – especially in gamification scenarios – where names could be used for a ranking order of a group (= option).
• In most cases, there is no need to limit the duration of a test in self-assessment (= standard setting); as it was worked out in the discussion in the working group, there might be situations where authors could like to choose a time limit (= option).
• Direct feedback is one of the most important features of self-assessment scenarios (= standard setting) although there might be situations where authors would like to deactivate it (= option). In all cases, participants should get access to the test results (= standard setting), but there are several options concerning the time of this access. Due to didactic reasons, the test results should always contain the best solution and the scored answers of the participant (= standard setting).
• “Show list of question” and “Flagging questions” are useful settings for the test-player self-assessment (= standard setting) but there should be the possibility to deactivate these features (= option).
• The “exam view” should be deactivated as a standard setting, but should be made an option, for example for learning sequences.
• In most cases, a notification is not necessary (= standard setting) but should be an option.
• There is no need for a test password, manually selected participants, a limited number of test passes, a test pass ID or a digital signature. These are typical settings for exams and can be generally deactivated for self-assessments (= standard settings).

 
Self-Assessment usually can be used by learners for a long period of time. It would therefore be useful to have the possibility of an error correction for active tests as it is also suggested in the feature wiki on the test-player for tests in learning objective driven courses (LoCs).



Details of the requirements were discussed in the working group Splitting-up Test&Assessment Working Group  and are stored in this document Matrix_Testeinstellungen_Self-Assessment.

 

3 User Interface Modifications

3.1 List of Affected Views

{Please list all views (screens) of ILIAS that should be modified, newly introduced or removed.}

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

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 Information

{ 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 Implications

{ 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: Bärenfänger, Maja [mbaerenfaenger], Rabah, Rachid [rabah]
• Maintainer: t.b.d.
• 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.

• …

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