Forum Discussion
Storyline 360 Quiz lockout after failed attempts(7-days cooldown)
It is very complex JavaScript engine to create and SCORM state-management challenge to fulfill your requirement. The main issue to consider is user manipulation. If you used a simple Date.now() countdown without properly storing the original unlock timestamp, a learner could potentially manipulate the browser / computer clock, refresh the course, or close and reopen the SCORM package and cause the timer to behave incorrectly. You need a reliable way to remember the exact moment when the quiz should become available again.
I would add the lock timestamp directly into SCORM suspend_data. But Storyline may continuously manage and update its own suspend_data and could later overwrite it, causing a timestamp to disappear.
The solution is to store the unlock timestamp in a dedicated Storyline variable, (eg. quizUnlockTimestamp), as a text value. The timestamp represents the exact future date and time when the quiz becomes available. Storyline then includes that variable in its own normal resume and suspend process. When the learner returns to the course, the script reads the stored timestamp, compares it with the current time, and calculates how much time is actually left. This means the countdown does not simply restart when the learner reopens the course; it continues based on the original unlock time.
The script also dynamically updates remainingTime so you can display the remaining time directly on the locked layer, while quizUnlocked changes to true only when the actual lock period has expired. The lock duration can easily be changed from minutes to hours or days without changing the rest of the logic.
Finally, the script includes SCORM API detection and should successfully detect the available SCORM version, so it should work with both SCORM 1.2 and SCORM 2004.
I built a simple Storyline file to test this logic and uploaded it to SCORM Cloud, and it seems to be working as expected. You may try the SCORM Cloud test link and see it for yourself. Let me know how it works for you and if you experience any issues. The current cooldown period is set to 1 minute purely for testing purposes. You may use a fake email address if you prefer when registering.The expected behaviour is as follows: Fail the quiz two times. Click the Retry button, and the Cooldown layer will appear. Close the course and reopen it (multiple times); the Cooldown layer should still be displayed, with the remaining time continuing to calculate correctly. Once the cooldown period expires, the Cooldown layer will automatically close, revealing the Failure layer underneath.
Clicking the Retry button again will provide two additional attempts. If the learner fails those two attempts as well, for a total of four failed attempts, the No More Attempts layer will be displayed.
It is very complex JavaScript engine to create and SCORM state-management challenge to fulfill your requirement. The main issue to consider is user manipulation. If you used a simple Date.now() countdown without properly storing the original unlock timestamp, a learner could potentially manipulate the browser / computer clock, refresh the course, or close and reopen the SCORM package and cause the timer to behave incorrectly. You need a reliable way to remember the exact moment when the quiz should become available again.
I would add the lock timestamp directly into SCORM suspend_data. But Storyline may continuously manage and update its own suspend_data and could later overwrite it, causing a timestamp to disappear.
The solution is to store the unlock timestamp in a dedicated Storyline variable, (eg. quizUnlockTimestamp), as a text value. The timestamp represents the exact future date and time when the quiz becomes available. Storyline then includes that variable in its own normal resume and suspend process. When the learner returns to the course, the script reads the stored timestamp, compares it with the current time, and calculates how much time is actually left. This means the countdown does not simply restart when the learner reopens the course; it continues based on the original unlock time.
The script also dynamically updates remainingTime so you can display the remaining time directly on the locked layer, while quizUnlocked changes to true only when the actual lock period has expired. The lock duration can easily be changed from minutes to hours or days without changing the rest of the logic.
Finally, the script includes SCORM API detection and should successfully detect the available SCORM version, so it should work with both SCORM 1.2 and SCORM 2004.
I built a simple Storyline file to test this logic and uploaded it to SCORM Cloud, and it seems to be working as expected. You may try the SCORM Cloud test link and see it for yourself. Let me know how it works for you and if you experience any issues. The current cooldown period is set to 1 minute purely for testing purposes. You may use a fake email address if you prefer when registering.
The expected behaviour is as follows: Fail the quiz two times. Click the Retry button, and the Cooldown layer will appear. Close the course and reopen it (multiple times); the Cooldown layer should still be displayed, with the remaining time continuing to calculate correctly. Once the cooldown period expires, the Cooldown layer will automatically close, revealing the Failure layer underneath.
Clicking the Retry button again will provide two additional attempts. If the learner fails those two attempts as well, for a total of four failed attempts, the No More Attempts layer will be displayed.