Synchronized Start of Test for All Participants

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

Currently the only way that a test can end in a controlled manner – with 'authorized' answers for all students still working on the test – is using the "Limit Duration of Test" setting. Using this setting finishes the test for each participant after the defined duration and saves all answers as 'authorized' so they will automatically be considered in the grading process. However, the countdown of the defined duration does not start until the participant clicked on the "Start the Test" button. Hence, the point in time when the test actually ends can vary from one participant to the next. This poses problems for exams where participants are supposed to start a test simultaneously and are supposed to be finished by a particular time.

Technically, this problem can be solved by setting starting and finishing times to limit access to the test in addition to using the "Limited Duration of Test" setting. However, pre-defined starting and finishing times are not a viable solution for many exams, as unexpected delays occur frequently and start and finishing times therefore need to remain flexible. Although it is always possible to adjust the pre-defined starting and finishing times, it is a rather cumbersome process that is prone to error in a high-stress situation like an exam.

2 Conceptual Summary

Similar to the dashboard button "Finish all Test Passes", that can be used to manually and simultaneously end a test for all participants that are still working on the test, there should be a "Start Test for all participants" (or similar) button to manually start a test for all participants simultaneously. Clicking this button would start the test globally and trigger the countdown of the duration set under "Limit Duration of Test".

For participants who already accessed the test and are presented the 'Info'-screen (with a notice in regard of the pending start of the test but no 'Start the Test’-button) the screen would then automatically switch into 'working mode’, displaying the first screen (first question or ‘List of Questions’, depending on settings). Any user accessing the test after it has been globally started will immediately enter the test in 'working mode' and be shown the first screen, the countdown timer displaying the globally remaining duration.

As a result, the countdown of a possibly defined duration will be exactly the same for all participants and all answers will be saved as 'authorized' as soon as such a defined duration is over.

For larger groups, it might be important to stagger starting times, so that the e.g. first 100 students start at time x, the next 100 e.g. 10 seconds later etc. This could either be done fully automatically, or the settings could be extended for the administrator to set the parameters (number of batches, stagger intervals) manually, depending on the performance of their system.

3 User Interface Modifications

3.1 List of Affected Views

• Test [admin view] > Settings
• Test [admin view] > Dashboard
• Test [admin view] > Info
• Test [user view] > Info

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

• Test [admin view] > Settings
  • In the section 'Administering the Test: Access' an option "Synchronized Start of Test" [checkbox] needs to be added.
    • An explanatory byline SHOULD be provided: “With this option the test has to be activated manually and simultaneously for alle participants from the dashboard. It cannot be started by the participants themselves."
    • A sub-section MUST be added to select "Stagger synchronized start" and to specify the staggering parameters "Number of participant per batch" and "Stagger interval".
  • When the above option is activated …
    • the date/time field for "Starting Time" MUST be disabled
    • the date/time field for "Finishing Time" SHOULD be disabled
    • the number of test passes ('Administering the Test: Test Run') MUST be limited to 1 (option "Limit Number of Test Passes")
  • In the section 'Information Before Start of Test' the byline to "Introductory Message" SHOULD be expanded with "If you have activated the 'Synchronized Start of Test', participants that are late to the test will not be shown this message."

Mock up "Administering the Test"

Mock up "Introductory Message"

• Test [admin view] > Dashboard
  • Add button "Synchronized Start" (German: "Synchron starten")
  • After clicking this button the Dashboard screen MUST refresh. After the refresh it MUST NOT show the button anymore.

Mock up Dashboard Admin view

• Test [admin view] > Info
  • Until an administrator has clicked the new button "Synchronized Start" on the test's Dashboard ...
    • the button "Start the Test" MUST be disabled or – preferably – hidden
    • an informative text "The test is not available yet. It has to be activated by a supervisor first." SHOULD be displayed in a suitable manner
    • (→ this being completely analogous to the present behaviour when a 'Starting Time' is set …)
  • As soon as an administrator has clicked the new button "Synchronized Start" on the test's Dashboard the Info tab screen of the administrator(s) MUST show the button ‘Start the Test’. It SHOULD NOT automatically switch into working mode for the administrator. Otherwise administrators might inadvertently find themselves right in the ‘working mode’ of the test (possibly even "locked" in ‘Exam View’) just by clicking the Info tab.
    • (→ In this the admin view of the Info tab diverges from the user view (see below).)

Mock up Info tab Admin view

• Test [user view] > Info
  • The Button "Start the Test" MUST be disabled or – preferably – hidden
  • Until an administrator has clicked the new button on the test's Dashboard an informative text "The test is not available yet. It has to be activated by a supervisor first." SHOULD be displayed in a suitable manner.
    • (→ this is analogous to the present behaviour when a 'Starting Time' is set ...)
  • As soon as an administrator has clicked the new button "Synchronized Start" on the test's Dashboard the Info tab screen of the participants switches automatically to working mode (with or without ‘Exam View’ according to the settings) and the first screen of the test is displayed (– i.e. the first question, or the 'List of Questions’ [which is to become 'Test Pass Overview' in ILIAS 9], according to the settings).
    This happens either synchronously for all participants or, in cases of large groups, staggered for defined batch sizes.
  • After an administrator has clicked the new button "Synchronized Start" on the test's Dashboard any 'new' participant accessing the test object is directly presented with the working mode view of the test (with or without ‘Exam View’ according to the settings) and the first screen of the test is displayed (– i.e. the first question, or the 'List of Questions’ [which is to become 'Test Pass Overview' in ILIAS 9], according to the settings).
  • → The timer always shows the same remaining time on the ‘working mode’ screens of all participants in the same batch, i.e. it differs for participants in different batches by the defined interval.

Mock up Info tab User view

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

No personal data is affected by this feature in any way.

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: Weber, Jens [jens.weber] / Thiel, Anja [athiel]
  
• 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.

• Universität Bern

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