In the final testing of a lesson we've discovered a bug where the learner can bypass a restricted Next button. It seems to provide a means of bypassing interactive content the should be required to be visited. This occurs pretty easily by simply navigating using the Previous button, and then hitting Next to return to the slide with the Next button magically unlocked.
What are the slide properties of the slide in question?
If the Next button isn't locked by a trigger that fires when the timeline starts, it should be. Whether the learner visits other slides, or just other layers makes a difference to whether you can expect success using "When state of buttons is Visited". If the slide is not set to Reset to initial state on revisit, you will lose the condition of the Next button, If it is, you will lose the Visited state of the buttons.
Thanks for your response. The next button is locked by having the trigger set as I described above, simply:
Change state of Next Button to Normal
When state of all of buttons is Visited
The interactive objects are buttons that have states assigned to them, when visited, these are assigned to layers on the same slide.
As for locking the Next button with timeline, I used to do that, however found that a Storyline update in the past no longer requires the timeline lock, if you use the simple trigger recipe described above. Try it and you'll see what I mean.
The Next button is truly restricted and will not unlock until you visit all the states. As for slide properties- Reset to Initial State, I have that setting too so that could be the issue since it's upon the slide revisit (navigate Previous and Next) that unlocks the Next button. That's why I'm reporting this as a bug.
I'll share a slide with an Articulate team member. Thanks!
I'm confused. You say "The next button is locked by having the trigger set as I described above, simply: Change state of Next Button to Normal
When state of all of buttons is Visited", but that unlocks it. How do you lock it in the first place? If you are using the player to restrict the menu and lock Next/Previous, that prevents the use of the Next button the first time the slide is visited, but not subsequent visits. The rationale for that is to permit the learner to freely return to previously visited slides. On the first visit, the restriction holds until released by the slide, in this case, by means of the trigger you describe, or leaving this slide (jumping to another unrestricted slide). After the initial visit, navigation becomes free to any unrestricted slides,
It seems that what you are experiencing is that the learner visits the slide. The menu registers that slide as visited, and moves it to the list of slides that are no longer restricted. The learner uses Previous to go back; from that slide uses Next to return to what is now a previously visited slide, and is free to use the Next button.
So this normal behavior is suitable if you want Next locked until the slide is visited, Opening the slide is considered visiting it. On the other hand, if you want it locked until the interactions are completed, you may need to manually restrict navigation.
Walt, I appreciate your input here. Look past the timeline Next button restriction, and consider this manner of restricting the navigation. I suppose a little mock up should help illustrate the bug or work around.
Walt, try testing again but this time just allow the timeline to complete on slide 2, THEN hit previous, then next again. I seem to be able to replicate.
It's almost as if Storyline is assigning a state of visited to the buttons just because the timeline has ended. Weird....
You're right. SL crashed before I got the next video recorded. Here it is.
I was wrong before when I said the slide was marked visited when opened. Thanks to this mock-up, I have a better idea of what actually happens, due to slide 1. When the timeline ends, the slide is marked as already visited. That means that the next time the learner visits it, they are free to jump from there to any other already visited slide. That is the distinction between restricted navigation, and locked navigation. The other action that happens at the end of a restricted slide is that Next is enabled, if there is no other trigger to enable it. When the timeline ends on Slide 1there is no trigger to enable Next, so it is enabled automatically, When the timeline ends on Slide 2, Slide 2 is marked as visited (very important). Since there is a trigger to enable Next, the second step is not taken. However when you go to previous, and come back, Next is not disabled when the slide starts, because Slide 2 has already been visited, and it now belongs to the list of unrestricted slides.
So no, SL is not assessing the states of the buttons as visited; it is assessing the condition of slide 2 as no longer restricted. If you were to click the buttons, when they are all visited, Next will be enabled. Wait - you won't notice it because it was never disabled in the first place, because the slide is now no longer restricted.
The answer is to expect this behavior, as the way restricted navigation is supposed to function. If that's a problem, create your own triggers to disable and enable Next. That's the best way to ensure the learner goes through the interactions. Or, you could make sure the timeline never reaches the end. Maybe you don't want to make the timeline that long, but you could pause it about a second before it comes to the end.
When the timeline ends on Slide 2, Slide 2 is marked as visited (very important). Since there is a trigger to enable Next, the second step is not taken.
This seems (as you pointed out) to be the important distinction here. In essence it's dueling triggers, one default (player) and one programmed (user).
Even though he has triggers in place to change the state of the Next button to normal when his states all equal visited, that's not the only trigger influencing the Next button. So when the slide reaches the end, the player trigger is enabling the Next button.
Took me a little bit, but thanks for the patient explanation Walt, much appreciated.
I would make a slight distinction. When the slide reaches the end, the player is not actually enabling the Next button, otherwise, it would change like Slide 1 does. The player is only marking the slide as visited. Then when the slide is revisited, the player is not disabling the Next button on start because this slide is visited..
But (most respectfully Walt)... the Slide Property is Reset to initial state, so I do not see how that is an acceptable means to bypass the assigned trigger.
And I would say that is where you disagree with the Articulate programmers: what is an appropriate list of what should be included in "Initial state". I'm not saying you are wrong, and it is certainly no loss to your reputation to disagree with Articulate. Many of us here do, at many points.
It looks like I will be reactivating a good many triggers in my lessons which were assigned to disable the Next button at the start of the timeline in this case.
Exactly when or how this came to be escapes me, perhaps back when the multi-trigger edit capability was rolled out. Which makes me think something got broke in the process because in-part this navigation restriction via state works till you try this work around- call it a "hack" if not a bug. Nevertheless at least these triggers are still in the cue.
Foremost, thank you Walt, and Brian for taking the time to look into this and lend your expertise.
13 Replies
How are you locking the Next button?
Where is the interactive content located?
What are the slide properties of the slide in question?
If the Next button isn't locked by a trigger that fires when the timeline starts, it should be. Whether the learner visits other slides, or just other layers makes a difference to whether you can expect success using "When state of buttons is Visited". If the slide is not set to Reset to initial state on revisit, you will lose the condition of the Next button, If it is, you will lose the Visited state of the buttons.
I can offer a couple of suggestions. Go to https://community.articulate.com/discussions/articulate-storyline/free-sample-restricted-and-free-random-navigation-using-variables-and-triggers. There is a sample on that discussion that avoids all these problems.
Or you can attach your .story file, and someone can give you an answer specific to your project.
Hi Walt,
Thanks for your response. The next button is locked by having the trigger set as I described above, simply:
Change state of Next Button to Normal
When state of all of buttons is Visited
The interactive objects are buttons that have states assigned to them, when visited, these are assigned to layers on the same slide.
As for locking the Next button with timeline, I used to do that, however found that a Storyline update in the past no longer requires the timeline lock, if you use the simple trigger recipe described above. Try it and you'll see what I mean.
The Next button is truly restricted and will not unlock until you visit all the states. As for slide properties- Reset to Initial State, I have that setting too so that could be the issue since it's upon the slide revisit (navigate Previous and Next) that unlocks the Next button. That's why I'm reporting this as a bug.
I'll share a slide with an Articulate team member. Thanks!
I'm confused. You say "The next button is locked by having the trigger set as I described above, simply: Change state of Next Button to Normal
When state of all of buttons is Visited", but that unlocks it. How do you lock it in the first place? If you are using the player to restrict the menu and lock Next/Previous, that prevents the use of the Next button the first time the slide is visited, but not subsequent visits. The rationale for that is to permit the learner to freely return to previously visited slides. On the first visit, the restriction holds until released by the slide, in this case, by means of the trigger you describe, or leaving this slide (jumping to another unrestricted slide). After the initial visit, navigation becomes free to any unrestricted slides,
It seems that what you are experiencing is that the learner visits the slide. The menu registers that slide as visited, and moves it to the list of slides that are no longer restricted. The learner uses Previous to go back; from that slide uses Next to return to what is now a previously visited slide, and is free to use the Next button.
So this normal behavior is suitable if you want Next locked until the slide is visited, Opening the slide is considered visiting it. On the other hand, if you want it locked until the interactions are completed, you may need to manually restrict navigation.
Walt, I appreciate your input here. Look past the timeline Next button restriction, and consider this manner of restricting the navigation. I suppose a little mock up should help illustrate the bug or work around.
Here's what I see when I click Prev, then Next
Walt, try testing again but this time just allow the timeline to complete on slide 2, THEN hit previous, then next again. I seem to be able to replicate.
It's almost as if Storyline is assigning a state of visited to the buttons just because the timeline has ended. Weird....
Brian,
You're right. SL crashed before I got the next video recorded. Here it is.
I was wrong before when I said the slide was marked visited when opened. Thanks to this mock-up, I have a better idea of what actually happens, due to slide 1. When the timeline ends, the slide is marked as already visited. That means that the next time the learner visits it, they are free to jump from there to any other already visited slide. That is the distinction between restricted navigation, and locked navigation. The other action that happens at the end of a restricted slide is that Next is enabled, if there is no other trigger to enable it. When the timeline ends on Slide 1there is no trigger to enable Next, so it is enabled automatically, When the timeline ends on Slide 2, Slide 2 is marked as visited (very important). Since there is a trigger to enable Next, the second step is not taken. However when you go to previous, and come back, Next is not disabled when the slide starts, because Slide 2 has already been visited, and it now belongs to the list of unrestricted slides.
So no, SL is not assessing the states of the buttons as visited; it is assessing the condition of slide 2 as no longer restricted. If you were to click the buttons, when they are all visited, Next will be enabled. Wait - you won't notice it because it was never disabled in the first place, because the slide is now no longer restricted.
The answer is to expect this behavior, as the way restricted navigation is supposed to function. If that's a problem, create your own triggers to disable and enable Next. That's the best way to ensure the learner goes through the interactions. Or, you could make sure the timeline never reaches the end. Maybe you don't want to make the timeline that long, but you could pause it about a second before it comes to the end.
This seems (as you pointed out) to be the important distinction here. In essence it's dueling triggers, one default (player) and one programmed (user).
Even though he has triggers in place to change the state of the Next button to normal when his states all equal visited, that's not the only trigger influencing the Next button. So when the slide reaches the end, the player trigger is enabling the Next button.
Took me a little bit, but thanks for the patient explanation Walt, much appreciated.
I would make a slight distinction. When the slide reaches the end, the player is not actually enabling the Next button, otherwise, it would change like Slide 1 does. The player is only marking the slide as visited. Then when the slide is revisited, the player is not disabling the Next button on start because this slide is visited..
But (most respectfully Walt)... the Slide Property is Reset to initial state, so I do not see how that is an acceptable means to bypass the assigned trigger.
Again, I appreciate the input you guys.
And I would say that is where you disagree with the Articulate programmers: what is an appropriate list of what should be included in "Initial state". I'm not saying you are wrong, and it is certainly no loss to your reputation to disagree with Articulate. Many of us here do, at many points.
Walt, I've got it now, and agree the slight distinction is also important here.
It looks like I will be reactivating a good many triggers in my lessons which were assigned to disable the Next button at the start of the timeline in this case.
Exactly when or how this came to be escapes me, perhaps back when the multi-trigger edit capability was rolled out. Which makes me think something got broke in the process because in-part this navigation restriction via state works till you try this work around- call it a "hack" if not a bug. Nevertheless at least these triggers are still in the cue.
Foremost, thank you Walt, and Brian for taking the time to look into this and lend your expertise.
This discussion is closed. You can start a new discussion or contact Articulate Support.