Forum Discussion
Storyline 360 Restricted Next behavior (sanity check)
Hi. For years I've assumed I needed a trigger to disable Next in order to override the built-in behavior of it enabling at the end of of a timeline for interactive slides. (i.e. I don't want Next to be active until the user has clicked a few things so I have two triggers: one that disables it and a trigger to re-enable it after all the conditions have been met.)
But in building a demo just now I stumbled onto this: just having a trigger on the slide that changes the state of Next seems to automatically override the enabling behavior.
(Run a slide in restricted mode without any other triggers and Next will enable at the end, then add a change state trigger
Can someone smarter than me confirm if is this new or has this always been the case? I have always built projects in free mode for easier testing, so I actually have needed a disable trigger to test all my clickables (so I hadn't noticed the behavior). This will simplify my life knowing I can drop one of those triggers.
Just putting this out there as an FYI for anyone else who was unaware.
Hey TedNunes,
Happy to jump in here.
I can confirm that EricSchaffer-d1 is correct. This functionality has been present in Storyline for a while. Restricted Navigation handles it all natively.
- 'Next' auto-disables on first visit, re-enables at the end of the Timeline, and stays enabled on any revisit.
The reason you needed the extra 'disable' Trigger with unrestricted navigation is that it doesn't have any of that built-in logic, so you had to manage both ends yourself. Adding any change-state Trigger targeting 'Next' signals to Storyline that you're managing the button state manually, so it overrides the auto-enable behavior and defers to your Triggers instead.
One of our Storyline gurus (JudyNollet) shared an excellent breakdown of all the ways to control the 'Next' button if you'd like to go deeper:
Please let us know if you have any more questions!
10 Replies
I believe it has been there for a long time now. I know a lot of people do some of the same things you have been doing, people I work with, but they miss this and make a lot more work for themselves.
Hey TedNunes,
Happy to jump in here.
I can confirm that EricSchaffer-d1 is correct. This functionality has been present in Storyline for a while. Restricted Navigation handles it all natively.
- 'Next' auto-disables on first visit, re-enables at the end of the Timeline, and stays enabled on any revisit.
The reason you needed the extra 'disable' Trigger with unrestricted navigation is that it doesn't have any of that built-in logic, so you had to manage both ends yourself. Adding any change-state Trigger targeting 'Next' signals to Storyline that you're managing the button state manually, so it overrides the auto-enable behavior and defers to your Triggers instead.
One of our Storyline gurus (JudyNollet) shared an excellent breakdown of all the ways to control the 'Next' button if you'd like to go deeper:
Please let us know if you have any more questions!
Well, this is an improvement, BUT... I just discovered that after the timeline reaches the end (and NEXT remains disabled), if I click Play again, NEXT will immediately enable and a user could skip the interaction. Is this an oversight or is there a reasoning behind that behavior?
That strikes me as very normal behavior. Many eLearning courses I've taken require you to see an entire video, or complete every interaction a page once. If I've already watched the video, I have the option of reviewing it, but there's no actual reason to lock me on the page if I only wanted to repeat the first minute, then go on. I've seen it already.
I would need to see your slide to fully understand what is happening and maybe help you with the why. If you like you can contact me directly and I can look at it for you. I would delete everything after.
TedNunes: As you've seen, a trigger can prevent NEXT from being automatically enabled when the timeline ends with Restricted navigation. In that same situation, notice that the Play button is disabled until the timeline ends. As you discovered, when you click it, the slide enables NEXT, as it would with just Restricted nav. I don't know the reasoning, but that might just be a programming oversight.
There is a workaround: Add a trigger that disables NEXT when the timeline starts*. That will run if the user clicks Play before they complete the interaction, so NEXT will stay disabled.
* A “when timeline starts” triggers runs every time the user reaches the slide—even if the Slide Properties are set to “Resume saved state.” If you don’t want the trigger to run in some situations, you need to add conditions to the trigger. For example, the conditions could check whether the state of buttons on the slide = Visited. Or a condition could check whether a T/F variable = True.
Thanks Judy. The trigger you're describing is what we've been already been doing for years, which means we have to have two triggers (1. force NEXT to stay disabled, 2. enable it when interaction is complete.)
My original post explains how I didn't realize until just recently that NEXT would automatically stay disabled by adding a single trigger targeted it. Hurray, we can drop the extra trigger.
But then this morning I realized that it WILL enable if you just click Play. It seems like a bug--why have the behavior to prevent NEXT from enabling if a trigger is there, but then enable it if Play is clicked regardless of that trigger firing (and not having left the slide yet)?
I work with Nurse educator SMEs who don't trust their students to not skip over things, so I have to be robust in my navigation restrictions. I was excited to be able to drop a trigger or two, but alas. Thanks everybody for your input.Hey TedNunes,
Thanks for digging into this further!
When a learner clicks 'Play' after the Timeline has completed, Storyline treats that as a fresh Timeline start. The Restricted Navigation's built-in logic re-enables 'Next' at the end of that replay, regardless of custom Triggers. So it's not quite that your Trigger is being ignored, but the auto-enable fires again on the new playback cycle.
Judy's workaround is currently the most reliable way to workaround this. However, as you've pointed out, it prevents you from including those additional Triggers. If you're comfortable sharing the .story file, we're happy to take a closer look and confirm that everything is working as expected.
Feel free to upload your project here in the discussion or privately through a support case.
Hi Steven, thanks for your clarification.
I'm attaching a file that demonstrates my issue (although, I think you get what I'm talking about here). I understand it's not an issue as far as Storyline is concerned but let me plead my case.
I still argue that this is buggy behavior, intentional or not. Overriding the NEXT button behavior (preventing it from automatically becoming active) based on the presence of a trigger targeting NEXT seems to indicate an understanding that the developer has set conditions the user must meet before getting an active NEXT, i.e. before leaving that slide.
Clicking Play again is something a user easily might do: on purpose to replay the introduction audio or content, or accidentally, since people click around randomly because they are fidgety. But they haven't left the slide yet, so I don't think that should be treated the same as other slide revisits.
I was already working without the knowledge that this was even a thing, so I'll live. I'm only so animated about this because, from my point of view, what is the point of that feature? It was frustrating that it's almost perfect for me, but that vulnerability is too great for me (and my educators) to trust it.
But you will see in my sample the trigger I have been using to disable NEXT. It's not just that I have to add another trigger, but for usability I also have to add a True/False variable condition so that THAT trigger WON'T disable NEXT on revisits (which also means another trigger to set that var to True when the interaction is complete. That's fine for me since I'm used to it, but I also have to (try to) train new, inexperienced IDs on my team, who don't always go to the trouble I do or understand why.
It seems like a small thing to just add a trigger that forces NEXT to stay disabled, but if they leave off the conditional vars, it will disable every time a user revisits a slide and they will have to click all the clickables again. (unless they use the menu to move on, but people don't always realize or remember they can do that.) We create training for over 200K employees and every minute of time wasted fumbling around can add up.
