From the tutorial: "Resume saved state: Use this option if you want the slide to always remember its previous state. In other words, this option lets learners pick up where they left off when they leave the slide and come back to it later."
I have routinely built slides where the Next button is disabled when timeline starts, and normal when timeline ends. When revisiting the slide, I set it to 'resume saved state.' With the recent updates, it appears this no longer works; when you revisit a slide, the Next button is disabled. What am I missing?
Hi, Kat -- Thank you for reaching out and sorry to hear of your troubles! May I ask if you are finding this issue when you test your course in the intended environment or where the course will ultimately be accessed by learners? And have you taken a look at the troubleshooting steps listed here to see if you find improvement? If issues persist and you are only noticing this behavior after Update 9, you would be welcome to connect with our Support Engineers, as well.
There is a known issue right now with the next button returning to a disabled state on a revisit to the slide, even if it's using the "resume saved state" set up. You can see similar discussion of this issue here and a few suggested ways to modify the slide to allow it to work normally such as using a variable.
I'll include this thread in the report filed with our team so that I can share any updates with you here once they are available.
Hello! Are there any updates on this issue? I'm having the same problem of a Next button returning to a disabled state even though I have Resume saved state when revisiting.
Hello Michele - I do not have an update at this time, but I do appreciate you popping in to let us know you are being impacted by this. We are trying to do better about prioritizing based on user impact.
You have a couple options for workaround:
adding these triggers to the Slide Master:
Change state of next button to disabled When the timeline reaches 0.5 seconds.
Change state of next button to normal When the timeline ends.
Any updates to this? It seem like a pretty straight forward issue; if you set the slide to "Resume saved state, it shouldn't fire a trigger that already played the first time.
I am experiencing the same issue. I am using the latest version of Storyline 360. In my slide, there is a trigger that says, enable the next button when 3 objects state are visited. When the slide is replayed, the 3 objects onscreen appear visited, and the timeline shows it is at the end, but the next button does not enable until you click on one of the objects that are already visited again. I tested this in Preview and published online in Articulate Review.
This is very common issue even in programming. Please check the triggers who executed first. It is safe not to execute all triggers to "When timeline starts" event. Try to change other trigger to "When timeline reaches to 0.25s if you have condition. Because not all states, variable values are available at the same time when timeline starts. That is why we need few seconds to make the variable value, states are available. :)
Change state of "next button" to "Disabled" When timeline starts
When revisiting: "Resume saved state"
If you go back one slide, the first trigger will fire anyways, and disable the next-button. the user is then stuck in the course, and the only way to advance is to restart the whole course and never click the back-button.
Did some more searching. The "timeline starts" trigger is supposed to always fire? It cant have been like that since the beginning, as I've uses these functions before.
I even tried using "when timeline reaches 0.25 sec" and "0.5 sec", and "2.0 sec", but its still returning to disabled instantly upon going back one slide. Are there known bugs to this at the moment? Because I cant seem to find a way to keep the next-button disabled untill the user have completed the requested actions. Going back to this slides renders the user unable to ever move forward again.
Thanks. I do not agree that this is "by design", as there is no reason why one cannot do a trigger the first time a slide loads, but not every time it loads even when the state is resumed.
I even tried using "when timeline reaches 2 sec", but it will still immediately trigger and set it as disabled when you revisit the slide. So there must be some sort of a bug there either way. If by design, it should still either take 2 sec to turn disabled upon revisiting a saved-state slide, or it should not trigger at all, as the timeline should not progress.
I have a deadline today, and it looks like I have to go over all my pages in all my current projects and add an invisible object with a "completed" state on it. Change the state of this object to complete, and do a condition on the next-button upon revisiting. Set state of Next-button to disabled when timeline starts if <State of Shape X> is not COMPLETED.
Does not look like an intended way of doing this, as its just not intuitive. Why do I need extra triggers and invisible object on the slide, with states, to prevent the button from being disabled upon revisiting a saved slide. Seems like a bug got in there somewhere, and they dont want to correct this. A lot of people must use this for of navigation.
Change state of next button to Disabled when the timeline starts if <Object that needed to be visisted to advance>'s state is not equal to Visited
But its still a workaround, and I should have to do this for a basic behavior like this.
So, as of now, storyline does not support "Prevent user from moving to next slide until the user have completed an action on current page. And also enable the user to revisit this slide without getting stuck forever"? And this is intended as "by design"? Weird decision :P
Or for that matter; Its not possible, by default, to perform any actions when timeline starts, only the first time the slide is viewed, even if it's set to resume saved state. Cant possibly be the intended way this should work. :P
I also have trouble believing this would be by design. If so, could you please inform us of the intent of such a design decision? I can't think of any reason anyone would want to resume saved state except for some of the triggers.
If this is truly the case, then there should be another slide revisiting option called, "Resume most of the saved state" for the current way it acts. Or leave "Resume saved state", as it is and add another option called "No really, resume saved state" that will actually resume the saved state.
The purpose seems straight forward, you either want the slide exactly where it was when the learner left the slide or you want it to reset and start from the beginning.
I'm glad that you were able to figure out the correct triggers needed for your course.
Each time you visit and re-visit a slide, the timeline re-starts.
The solution that you've found is similar to the instructions that we share here when you wish to restrict navigation with the prev/next button for some slides.
@Michael: Indeed. On the serious side, for this to make any sense at all, there should be another trigger. One is the "when timeline starts", and one should be "when slide loads".
@Leslie: The timeline might re-start, but it should not trigger the "start", as it never starts upon resuming saved state. It resets, but should not start. And if it does not start, it should not trigger the "when timeline starts" action.
No, in the example you provide there are no "logic" behind the state. It simply overrides the disabling of the next-button anytime you visit a slide with this trigger, even if the user have not performed the requested actions needed to advance to the next slide.
My issue is that I see no logical reason for why a trigger named "when timeline starts" to fire, when revisiting a side with saved state.
The current behavior will also prevent me from other actions tied to the timeline, if the timeline is reset to start even though its set to save states. Say I have a slide, where at 5, 10, 15 and 20 sec I pause the timeline. An individual animation happens inbetween these 5 second gaps. When the user presses a button, the timeline resumes, and shows the next animation. If I only click the button twice, go to the next page, and come back, its all reset? Even with the save states enabled? I would then have to do 2 empty clicks and wait 10 seconds, before I could continue with my 3rd animation?
I've passed your comments along to our Engineering team. I will report back if I hear of additional information to share. Thanks for sharing what would be a beneficial addition to your build!
"When timeline starts" Should in my head only fire when the timeline actually starts.
The current behavior could be called "When slide loads" or "When timeline loads" or similar, to distinct it from always happening, og only first time visiting if slide is set to resume saved.
Quick question, outside of this. If I have a result slide, and want to submit a lot of questions. This could take some time to reach the LMS? Will the next action wait for the previous to complete? If I have "Submit results xxx when timeline starts", and then a "Jump to slide Next Slide when timeline starts" following. Would it wait for the submit action to complete, or would it jump as soon as possible, possibly aborting the submitting data?
I would recommend adding a results slide instead of a "Submit results" trigger. This way the LMS will track the score from your course without any extra steps.
If you're going to add a "Submit Results" trigger, I would recommend attaching it to a button. This will create a more seamless process.
As of 2021, it's still a thing. Considering that this is an over five years oldproblem with workarounds that only sometimes kinda works if storyline feels like it, a basic functionality issue is clearly not a priority.
In Storyline, the timeline-starts trigger event occurs every time the slide displays. So the timeline-starts trigger always executes when the learner revisits the slide, even if it resumes its saved state.
I understand that this behavior might not be ideal for some, and we'd like to hear your thoughts on how this feature can be enhanced or improved through a feature request!
27 Replies
Hi, Kat -- Thank you for reaching out and sorry to hear of your troubles! May I ask if you are finding this issue when you test your course in the intended environment or where the course will ultimately be accessed by learners? And have you taken a look at the troubleshooting steps listed here to see if you find improvement? If issues persist and you are only noticing this behavior after Update 9, you would be welcome to connect with our Support Engineers, as well.
I am previewing the course. It's always worked in preview.
Hi Kat,
There is a known issue right now with the next button returning to a disabled state on a revisit to the slide, even if it's using the "resume saved state" set up. You can see similar discussion of this issue here and a few suggested ways to modify the slide to allow it to work normally such as using a variable.
I'll include this thread in the report filed with our team so that I can share any updates with you here once they are available.
Hello! Are there any updates on this issue? I'm having the same problem of a Next button returning to a disabled state even though I have Resume saved state when revisiting.
Hello Michele - I do not have an update at this time, but I do appreciate you popping in to let us know you are being impacted by this. We are trying to do better about prioritizing based on user impact.
You have a couple options for workaround:
adding these triggers to the Slide Master:
Any updates to this? It seem like a pretty straight forward issue; if you set the slide to "Resume saved state, it shouldn't fire a trigger that already played the first time.
Hey Michael!
Since this is an older thread, I'd like to start fresh. It sounds like you're having some trouble with the Resume Saved State setting.
Can you help me with a few more details?
I am experiencing the same issue. I am using the latest version of Storyline 360. In my slide, there is a trigger that says, enable the next button when 3 objects state are visited. When the slide is replayed, the 3 objects onscreen appear visited, and the timeline shows it is at the end, but the next button does not enable until you click on one of the objects that are already visited again. I tested this in Preview and published online in Articulate Review.
hi,
This is very common issue even in programming. Please check the triggers who executed first.
It is safe not to execute all triggers to "When timeline starts" event. Try to change other trigger to "When timeline reaches to 0.25s if you have condition. Because not all states, variable values are available at the same time when timeline starts. That is why we need few seconds to make the variable value, states are available. :)
Hey Shawna,
It looks like Rex has popped in with some helpful advice.
If you need us to take a look at your .story file, feel free to share and just let us know what slide to focus on :)
Hi,
I'm having the same exact problems.
How come this is still not yet fixed???
Did some more searching. The "timeline starts" trigger is supposed to always fire? It cant have been like that since the beginning, as I've uses these functions before.
I even tried using "when timeline reaches 0.25 sec" and "0.5 sec", and "2.0 sec", but its still returning to disabled instantly upon going back one slide. Are there known bugs to this at the moment? Because I cant seem to find a way to keep the next-button disabled untill the user have completed the requested actions. Going back to this slides renders the user unable to ever move forward again.
Hi Stan
I remembered seeing this post recently - not sure if it helps you
Thanks. I do not agree that this is "by design", as there is no reason why one cannot do a trigger the first time a slide loads, but not every time it loads even when the state is resumed.
I even tried using "when timeline reaches 2 sec", but it will still immediately trigger and set it as disabled when you revisit the slide. So there must be some sort of a bug there either way. If by design, it should still either take 2 sec to turn disabled upon revisiting a saved-state slide, or it should not trigger at all, as the timeline should not progress.
I have a deadline today, and it looks like I have to go over all my pages in all my current projects and add an invisible object with a "completed" state on it. Change the state of this object to complete, and do a condition on the next-button upon revisiting. Set state of Next-button to disabled when timeline starts if <State of Shape X> is not COMPLETED.
Does not look like an intended way of doing this, as its just not intuitive. Why do I need extra triggers and invisible object on the slide, with states, to prevent the button from being disabled upon revisiting a saved slide. Seems like a bug got in there somewhere, and they dont want to correct this. A lot of people must use this for of navigation.
Even quicker workaround:
Change state of next button to Disabled
when the timeline starts
if <Object that needed to be visisted to advance>'s state is not equal to Visited
But its still a workaround, and I should have to do this for a basic behavior like this.
So, as of now, storyline does not support "Prevent user from moving to next slide until the user have completed an action on current page. And also enable the user to revisit this slide without getting stuck forever"? And this is intended as "by design"? Weird decision :P
Or for that matter;
Its not possible, by default, to perform any actions when timeline starts, only the first time the slide is viewed, even if it's set to resume saved state. Cant possibly be the intended way this should work. :P
I also have trouble believing this would be by design. If so, could you please inform us of the intent of such a design decision? I can't think of any reason anyone would want to resume saved state except for some of the triggers.
If this is truly the case, then there should be another slide revisiting option called, "Resume most of the saved state" for the current way it acts. Or leave "Resume saved state", as it is and add another option called "No really, resume saved state" that will actually resume the saved state.
The purpose seems straight forward, you either want the slide exactly where it was when the learner left the slide or you want it to reset and start from the beginning.
Hi Stian,
I'm glad that you were able to figure out the correct triggers needed for your course.
Each time you visit and re-visit a slide, the timeline re-starts.
The solution that you've found is similar to the instructions that we share here when you wish to restrict navigation with the prev/next button for some slides.
@Michael: Indeed. On the serious side, for this to make any sense at all, there should be another trigger. One is the "when timeline starts", and one should be "when slide loads".
@Leslie: The timeline might re-start, but it should not trigger the "start", as it never starts upon resuming saved state. It resets, but should not start. And if it does not start, it should not trigger the "when timeline starts" action.
No, in the example you provide there are no "logic" behind the state. It simply overrides the disabling of the next-button anytime you visit a slide with this trigger, even if the user have not performed the requested actions needed to advance to the next slide.
My issue is that I see no logical reason for why a trigger named "when timeline starts" to fire, when revisiting a side with saved state.
The current behavior will also prevent me from other actions tied to the timeline, if the timeline is reset to start even though its set to save states. Say I have a slide, where at 5, 10, 15 and 20 sec I pause the timeline. An individual animation happens inbetween these 5 second gaps. When the user presses a button, the timeline resumes, and shows the next animation. If I only click the button twice, go to the next page, and come back, its all reset? Even with the save states enabled? I would then have to do 2 empty clicks and wait 10 seconds, before I could continue with my 3rd animation?
Hi Stian!
I've passed your comments along to our Engineering team. I will report back if I hear of additional information to share. Thanks for sharing what would be a beneficial addition to your build!
Thanks. :)
"When timeline starts" Should in my head only fire when the timeline actually starts.
The current behavior could be called "When slide loads" or "When timeline loads" or similar, to distinct it from always happening, og only first time visiting if slide is set to resume saved.
Quick question, outside of this. If I have a result slide, and want to submit a lot of questions. This could take some time to reach the LMS? Will the next action wait for the previous to complete?
If I have "Submit results xxx when timeline starts", and then a "Jump to slide Next Slide when timeline starts" following. Would it wait for the submit action to complete, or would it jump as soon as possible, possibly aborting the submitting data?
Hello Stian!
I would recommend adding a results slide instead of a "Submit results" trigger. This way the LMS will track the score from your course without any extra steps.
If you're going to add a "Submit Results" trigger, I would recommend attaching it to a button. This will create a more seamless process.
As of 2021, it's still a thing. Considering that this is an over five years old problem with workarounds that only sometimes kinda works if storyline feels like it, a basic functionality issue is clearly not a priority.
Still an issue in 2023. I am hoping this bug gets escalated since working around variables is not always an option when working on larger projects.
Thank you!
Yes, this is still an issue in December 2023.
Hello Alexander,
Happy to chime in!
I wanted to share this article which explains why the behavior that is discussed in this thread is working as designed:
In Storyline, the timeline-starts trigger event occurs every time the slide displays. So the timeline-starts trigger always executes when the learner revisits the slide, even if it resumes its saved state.
I understand that this behavior might not be ideal for some, and we'd like to hear your thoughts on how this feature can be enhanced or improved through a feature request!