I am using Articulate 360 and currently working on a project which has saved states on multiple slides and multiple occasion and which is not working after the the recent updates. Please help. Thanks
We're seeing some issues in the most recent update of Storyline 360 where Drag-and-Drop slides aren't saving their states. Instead, the drag objects are returning to their original positions when the slide is revisited.
Does that sound similar to what's happening in your file?
We're also encountering problems with file states and triggers depending on it. I've added our Storyline file in the attachment.
In this file, the button to submit an interaction should change in state after reaching the maximum amount of attempts or submitting the correct answer. The built in 'next button' changes behaviour depending on the state of the custom submit button.
However, this functionality isn't working anymore after the recent update(s).
Thanks so much for sharing your file with me. I tested it in both Storyline 360 and Storyline 3, and it appears to be working the same way in both versions.
My apologies, I could have been more clear in describing the problem. I've added a comment on your video capture.
What should occur is the state 'normal' applied to the next button permanently after submitting the final answer to a question. The state of the submit button should also stay 'hidden'.
What happens now when going back a page is the state of the next button being disabled again, even though the triggers should change the state of the submit button to 'hidden' and the state of the next button to 'normal'.
Could you confirm if this happens to you as well? And tell us if this is caused by the most recent update to Storyline 360?
Would it help you if I publish a video schowing the functionality working in the storyline file, and the changes to it after the most recent updates? Thanks in advance,
Hi there, Bart. Thanks for clarifying! I see what was happening. You had a trigger to change the state of the Next button to normal if the Indienen button was hidden. The Indienen button was changing to the hidden state on your feedback layers. When revisiting the slide using the Previous button, however, Indienen was not hidden.
Instead of using states in your conditions, I would use a variable. I realize you have a few variables in your project already, but they really are the most consistent way to carry information across many slides.
I set a true/false variable answered and applied it to the trigger to disable the Next button. The trigger to change the Next button to disabled works when the timeline starts IF the variable is false. The variable is adjusted to true when they click the Indienen button. When users first see the slide, the Next button is disabled because they haven't clicked Indienen. When they revisit the slide, they've already clicked Indienen, so the Next button remains active.
Have a look at your modified file with slide 2.1 containing the changes! I hope that helps. Oh, and if you use this method, give your variables a better name than I did! :D
Thank you for your thorough investigation and subsequent advice on our custom functionality.
From what I understand was the correct working of our e-learning dependent on state changes, which are less reliable than variables. Would I be correct in concluding that working with variables is always preferable to working with states for custom functionality, in that Articulate Storyline does not guarantee (near) full reliability for object state behaviour?
If so, we will need to change our building procedure to use variables as a standard. Since that requires quite a bit of work I'm asking you to be sure.
Variables will offer you access to that value across slides, whereas a state will be specific to a slide and an object. So based on your design needs, it sounds like variables are the path to head on.
One of my favorite descriptions of variables came from another user here in ELH, Walt. Although it's a bit cheeky of a description, I think it really helps drive home the point of when and how variables can help track and keep information throughout a course.
We are also experiencing this issue and were fortunate that we had access to an older version of SL 360 (developer had not updated yet) (v3.15.xxxx). The version we consistently experience issues with screen not reliably saving their resumed state is v3.17.16188.0. This is affecting functionality that enables a Next button on completion of a screen. When navigating backwards, the enabled Next button state is not retained.
Hi Alyssa, my issue is not related to Drag and Drop exercises. My issue is as follows:
At the end of an activity, an object on stage is hidden, using a trigger (the object masks the next button). When revisiting the page, the mask is visible again in v3.17.16188.0 butnot visible, as expected in v3.15.xx. We have all pages set to Resume Saved State, and other objects on page are resuming their saved state.
The issue appears both in the preview mode and published HTML.
I just commented on another question similar to this.
Have you ensured you are publishing to SCORM 2004 4th edition?
Using saved state, many variables, many quizzes, etc., tries to save a lot of data to the suspend_data field of SCORM. Once you exceed the limit, it can cause all sorts of odd behaviors.
The SCORM specs give the following lengths for the suspend_data element:
Hi Scott. This isn't a SCORM issue for me and is an issue introduced by a new release of SL360. We have confirmed this by publishing the content in a previous version of SL360.
Just thought it might be another avenue for troubleshooting.
For us, the issue was how much data was being used by Articulate for keeping track of things. And when the available limits were exceeded, things like buttons appearing when they shouldn't, disappearing when they shouldn't, variable values populated with seemingly random numbers, etc., were all happening.
Being we are still using SL2, I'm not aware of how Articulate might be changing data handling between the various versions. Good luck figuring things out.
Hey, SCORM Cloud -- hmm, it sounds like you're seeing something different. Mind if I have a look at your file? You can attach it to a new reply, or share it privately here.
Hi, Sue -- thanks for confirming that. We'll let you know as soon as this bug in Storyline 360 is resolved!
19 Replies
Hi Sibi!
We're seeing some issues in the most recent update of Storyline 360 where Drag-and-Drop slides aren't saving their states. Instead, the drag objects are returning to their original positions when the slide is revisited.
Does that sound similar to what's happening in your file?
Hi,
We're also encountering problems with file states and triggers depending on it. I've added our Storyline file in the attachment.
In this file, the button to submit an interaction should change in state after reaching the maximum amount of attempts or submitting the correct answer. The built in 'next button' changes behaviour depending on the state of the custom submit button.
However, this functionality isn't working anymore after the recent update(s).
Hi Bart,
Thanks so much for sharing your file with me. I tested it in both Storyline 360 and Storyline 3, and it appears to be working the same way in both versions.
You can watch a video of my testing right here.
Is that not what you're seeing on your end? Can you tell me more about what should happen when the user presses the Submit button?
Hi Alyssa,
My apologies, I could have been more clear in describing the problem. I've added a comment on your video capture.
What should occur is the state 'normal' applied to the next button permanently after submitting the final answer to a question. The state of the submit button should also stay 'hidden'.
What happens now when going back a page is the state of the next button being disabled again, even though the triggers should change the state of the submit button to 'hidden' and the state of the next button to 'normal'.
Could you confirm if this happens to you as well? And tell us if this is caused by the most recent update to Storyline 360?
Best regards,
Bart
Dear Alyssa,
Would it help you if I publish a video schowing the functionality working in the storyline file, and the changes to it after the most recent updates?
Thanks in advance,
Bart Beukman
Hi there, Bart. Thanks for clarifying! I see what was happening. You had a trigger to change the state of the Next button to normal if the Indienen button was hidden. The Indienen button was changing to the hidden state on your feedback layers. When revisiting the slide using the Previous button, however, Indienen was not hidden.
Instead of using states in your conditions, I would use a variable. I realize you have a few variables in your project already, but they really are the most consistent way to carry information across many slides.
I set a true/false variable
answeredand applied it to the trigger to disable the Next button. The trigger to change the Next button to disabled works when the timeline starts IF the variable is false. The variable is adjusted to true when they click the Indienen button. When users first see the slide, the Next button is disabled because they haven't clicked Indienen. When they revisit the slide, they've already clicked Indienen, so the Next button remains active.Have a look at your modified file with slide 2.1 containing the changes! I hope that helps. Oh, and if you use this method, give your variables a better name than I did! :D
Hi Crystal,
Thank you for your thorough investigation and subsequent advice on our custom functionality.
From what I understand was the correct working of our e-learning dependent on state changes, which are less reliable than variables. Would I be correct in concluding that working with variables is always preferable to working with states for custom functionality, in that Articulate Storyline does not guarantee (near) full reliability for object state behaviour?
If so, we will need to change our building procedure to use variables as a standard. Since that requires quite a bit of work I'm asking you to be sure.
Thank in advance for your time,
Bart
Hi Bart,
Variables will offer you access to that value across slides, whereas a state will be specific to a slide and an object. So based on your design needs, it sounds like variables are the path to head on.
One of my favorite descriptions of variables came from another user here in ELH, Walt. Although it's a bit cheeky of a description, I think it really helps drive home the point of when and how variables can help track and keep information throughout a course.
We are also experiencing this issue and were fortunate that we had access to an older version of SL 360 (developer had not updated yet) (v3.15.xxxx). The version we consistently experience issues with screen not reliably saving their resumed state is v3.17.16188.0. This is affecting functionality that enables a Next button on completion of a screen. When navigating backwards, the enabled Next button state is not retained.
Yes!!! this is my issue. What can I do?
Hey SCORM Cloud and Sue,
Thanks for chiming in! Are you both seeing an issue when revisiting Drag and Drop slides? If so, that's an issue our team is tackling right now.
When you revisit a drag and drop slide, the objects should remain where they were dropped--they should not return back to their original positions.
Let me know if this is what you were seeing, or if there's something else going on!
Hi Alyssa, my issue is not related to Drag and Drop exercises. My issue is as follows:
At the end of an activity, an object on stage is hidden, using a trigger (the object masks the next button). When revisiting the page, the mask is visible again in v3.17.16188.0 butnot visible, as expected in v3.15.xx. We have all pages set to Resume Saved State, and other objects on page are resuming their saved state.
The issue appears both in the preview mode and published HTML.
I just commented on another question similar to this.
Have you ensured you are publishing to SCORM 2004 4th edition?
Using saved state, many variables, many quizzes, etc., tries to save a lot of data to the suspend_data field of SCORM. Once you exceed the limit, it can cause all sorts of odd behaviors.
The SCORM specs give the following lengths for the suspend_data element:
[Spec / Characters]
SCORM 1.2 / 4,096
SCORM 2004 2nd Edition / 4,000
SCORM 2004 3rd Edition / 64,000
SCORM 2004 4th Edition / 64,000
Hi Scott. This isn't a SCORM issue for me and is an issue introduced by a new release of SL360. We have confirmed this by publishing the content in a previous version of SL360.
Yes - my issue is related to the drag and drop objects returning to the starting position when revisited.
Just thought it might be another avenue for troubleshooting.
For us, the issue was how much data was being used by Articulate for keeping track of things. And when the available limits were exceeded, things like buttons appearing when they shouldn't, disappearing when they shouldn't, variable values populated with seemingly random numbers, etc., were all happening.
Being we are still using SL2, I'm not aware of how Articulate might be changing data handling between the various versions. Good luck figuring things out.
Hey, SCORM Cloud -- hmm, it sounds like you're seeing something different. Mind if I have a look at your file? You can attach it to a new reply, or share it privately here.
Hi, Sue -- thanks for confirming that. We'll let you know as soon as this bug in Storyline 360 is resolved!
I have just updated to the latest patch, and it my issue appears to have been resolved.
Thanks for the follow-up, SCORM Cloud!
This discussion is closed. You can start a new discussion or contact Articulate Support.