Quiz Review Player Next and Previous automatically enables

We are having problems with Graded quiz reviews Storyline 360 , although not inclusive of branching graded quiz questions the problem is particularly troublesome when there is multiply branched/conditionally controlled slide advancement!

Desired Results:

  1. When in review mode (a revisit to a Graded Quiz that has had it's interaction submitted) the player should honour the request of the slide properties not to display the players next and previous buttons.
  2. If triggers are in place for player control  when the actual player control is disabled via the slide properties it shouldn't break the display or modification of triggers coded for that player control.
  3. Do this without extra slides that perform branching between graded question slides

Results when using branching:

With the player next and previous buttons are disabled on the slide properties by design and intention:

When client uses the slides in Review Mode the Next and Previous player buttons turn on regardless of the settings on the slide.

As a result When we have branching quizzes we must now code triggers for branching on  Player Next and Previous clicks.

  • We code the Previous and Next Player trigger events with branching conditions.
  • Automatically the slides properties Player Previous and Next Player buttons checkmarks turn on.
  • We Turn the slide properties Players Next and Previous check marks off so in non-review mode they do not appear.
  • The triggers for the Next Previous player buttons now appear on the "slide triggers" grouping with the text on screen saying "when user clicks" with out the text "the next button" . Normally these triggers display in the "Player Triggers" grouping with the text "When the user clicks the next button". Note that "Player Trigger" grouping disappears completely if all player buttons are disabled via the slide property settings. If there are "Player Trigger" grouping should always appear!
  • If I go to edit the triggers for the player Previous and Next (with Slide next Previous slide properties disabled) the object chosen for the click event  shows up as unassigned when it should be showing Player Next or Player previous depending on how we coded the trigger.
  • If we turn players Next and Previous player buttons back on via slides properties the triggers will display and edit correctly. But we must have these buttons not displayed so as a editor I am always fighting the player.



4 Replies
Alyssa Gomez

Hi there Daniel! 

When learners review a quiz (or revisit question slides they've already submitted), they'll see Articulate Storyline's built-in Prev and Next buttons in the lower right corner of the player—even if you've disabled them throughout your course. This is because Storyline assumes the learner will need these buttons to progress from one slide to the next during quiz review.

Do you have custom buttons on your slide that will allow the learner to move forward during quiz review?

If so, try this:

  • Open the slide master.
  • Locate the "question" layout.
  • Add these triggers to that layout:
    • Change state of Next button to Hidden when the timeline starts.
    • Change state of Previous button to Hidden when the timeline starts.
  • Close the slide master.
  • Preview the quiz.

I learned that method from another community member, Wendy. Check out her Peek recording of those steps here! 

Daniel McHugh

Yes we have built in navigation and this is why we disable the previous and next via the slide base layer preferences.

Key to this problem is the assumption that the user needs the previous and next buttons when the developer has made the conscious decision to not have them available to the end user and then not giving the developer any warning or indications that they are enabled under such circumstance. The interface should be telling or indicating or giving us interface to change this behaviour exactly where we thought we turned it off. This undocumented feature seems to be more of an after thought then as part of design.

Your solution may work but it definitely gets in the way of developing. For every slide that has review I must now go through extra hoops and loops to get a base functionality that base slide layer properties is supposed to give.

At least give us back control and eliminate developer error/support problems? This can't be so esoteric problem. You probably haven't heard enough complaints from developers as they may not appropriate test their elearn's to have noticed that it's broken for them! Hey some of our organizations developers missed this problem for almost two years simply because you enable them in review with out telling us and we didn't adequately test the review functionality! If you can assume the end user needs the previous and next buttons at least assume the developer also needs to know when you take this decision away when and where they explicitly ask for it to be turned off in your interface.