Forum Discussion
Storyline 360 Restricted Next behavior (sanity check)
- 23 days ago
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!
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.
- StevenBenassi4 days agoStaff
Hey TedNunes,
Thanks for following up and sharing your file.
This behavior does look similar to two bugs we have logged for Storyline. I'd like our support engineers to have a closer look at this issue, so I've opened a support case on your behalf. You're in excellent hands with them, and they should be connecting with you shortly.
We can continue the conversation there!
Related Content
- 4 months ago