17 Replies
Bart Beukman

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).

Alyssa Gomez

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?

Bart Beukman

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

 

Crystal Horn

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

Bart Beukman

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

 

 

 

 

 

Ashley Terwilliger

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.

SCORM Cloud

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.

Alyssa Gomez

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!

SCORM Cloud

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.

Scott Wiley

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

Scott Wiley

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.