Forum Discussion
Storyline 360 - Visited states seem a bit buggy
PROBLEM: It would appear that the 'visited' state is not as consistent in SL360 compared to SL2. I want to know whether this is just my experience (i.e. my files), or whether other people are experiencing it (a bug).
(simplified) USE CASE: As a user, I arrive on a page that has 3 buttons that link out to other slides. The trigger disables the 'Next' button when the timeline starts. When I click each button, it goes to a 'visited' state. When all 3 buttons are visited, the Next button becomes 'Normal'.
MY NOTES: I use this technique (Visited State) because variables are 'one-layer-down' on the GUI, and therefore are not as efficient to manage for maintenance and changes. They also require higher level technical skills (cost/time).
Long-story-short is, I'm being forced to use the more inefficient method of variables because the States trigger is haphazard and doesn't work 'first-time-every-time' (even though I template the slides to use the same setup every time).
21 Replies
What's your slide's "When revisiting" set to? Automatically decide? Or Reset to Initial State?
I've set them to 'Resume Saved State'.
Hey, Tim! You definitely don't need to use variables for this. Take a look at this quick sample file I put together for you. Do the triggers in your file match the triggers in the sample file? Specifically, pay close attention to the trigger that changes the state of the Next button to Normal:
Hi Alyssa,
Thanks for the feedback. And yes, that's exactly how I've set up the trigger, but it works inconsistently in SL360, hence I've had to do a 'workaround' with variables. To be fair, it only seems to be happening when the client is navigating all over the place, and I've had trouble repeating the problem. Hence, I wanted to see if this was an issue across the board, or just with me.That trigger example works great, but what if I want the learner to go through an entire set of slides and only have a button activate once they have seen all the slides? (For example, a menu where I want them to go through two sections and see all the slides prior to taking a test.) In your example they could select Button 1 or Button 2 and immediately go back to the menu and not have viewed they rest of the slides.
A simple rule I tend to use for most scenarios is:
If open navigation is allowed, then use STATES
IF linear/controlled navigation is required, then use VARIABLESThe additional caveat would be the eye-ball test. i.e. if there are obviously a LOT more Triggers OR States OR Variables required to achieve the same result, then maybe it's worth re-thinking your practices :)
In a case like the one you've mentioned, it's very similar to the 'Restricted' option found in Player/Menu/Settings in Storyline. i.e. Free, Restricted, or Locked.
So, it would make sense to have a single variable trigger on the last slide IF the navigation to all the slides is linear. However, if the navigation to all the slides is NOT linear, then States is more efficient as a development strategy.
A case for Variables: A slide has 2 buttons on it, linking to two sections, each with a linear set of slides. On the last slide of each section, you could set a variable (eg. section1_complete=TRUE).
When section1_complete=TRUE AND section2_complete=TRUE, then the 'Test' button becomes 'Normal'.
A case for States: A slide has 20 objects on it, each linking out to 20 slides that make up 10 slides for section 1, and 10 slides for section 2, When all 20 slides are visited, the 'Test' button becomes 'Normal' (clickable).
Both options will work, so for me it comes down to efficiency of build, and cost of maintenance (simple solutions = lower costs).
Hope that helps :)
I use states a lot, variables are death by a thousand cuts as they are always global and you will hate yourself for using them when a project hits 100+ slides.
The behaviour you describe I have not seen. When I revisit slides where I have set states on items, they keep their state as I expect them to
Tim,
The behavior you describe is exactly what I have found in SL2. Complex navigation away from the page can cause the states to get lost and forgotten.
This is actually doing my head in a little bit. I've got 2 x major projects I'm working on, and i can't get the consistency I need.
When I try and recreate the problem in a blank Storyline file (2 or 360), it works fine (see attached). Then, over the course of creating the content, something happens, and it doesn't work any more. I'd love to know what's corrupting it so I can avoid/fix it.
I've stripped back one of my projects, to just the slide that contains the trigger, and it started to work again! I'll keep trying to nail this and let you know how it goes.My next step is to remove one slide at a time, and then layer by layer, and then object by object. Very time consuming, but hopefully I'll come up with something.
Any suggestions are most welcome.
Ok. Getting a LOT closer. There are two files attached, one that works, and one that doesn't. I've been able to narrow it down to a predictable outcome.
File 1: _FAIL - This one has:- The content sitting on a layer (rather than the base slide)
- Triggers on the buttons to hide the prompts
IF you remove EITHER of the above items, the States functionality works as expected.
(see File 2: _FAIL_FIXED)Again... would love to know what is triggering this issue to begin with. Any thoughts still welcome!
Tim,
I've been saying since SL2 was new that "State of ... is ..." is not an action, therefore it does NOT belong in the "When" part of a trigger. There is literally nothing for the trigger to monitor that will initiate its action. Most of us read it as State BECOMES, which is an action. It would be great if the programmers would make it a true ""State of ... BECOMES...", because then the trigger would have some action to initiate it, and we could use it.
I suspect that when an action occurs (like a click) the slide runs through the list of triggers, checking the list of actions to monitor. If it is reading that exact trigger and the states are all true at that exact instant, it fires, because sometimes the "State of ... is ..." actually functions correctly. If the state hasn't changed yet when it gets to that trigger, it fails, as your project proves. It doesn't come back to the list, because the change of state itself apparently doesn't raise an action.
If the timing isn't exactly perfect (the user is lucky), it doesn't work. Your sample is the best evidence I have to support that theory. Thank you for isolating this problem. I will be starting a support case.
As to the exact reason why this doesn't work, it is the other triggers. By the time an object runs through those other triggers, and reports that its state has changed, the slide has run through it list of triggers, checked the "State ... of ... is", found it not true, and ignored it. Until the programmers make a change of state raise an event, it is not a reliable action for the When portion of a trigger.
BTW, it works great in conditions, where it belongs.
Hi Walt,
Thanks, and I would tend to agree, except that just moving the objects onto the Base instead of a layer, will also remove the issue, so therefore it's not the triggers, or the order of the triggers that is creating the problem.
And, if I build it from scratch, it works fine. This is definitely a bug. A corruption is occurring somewhere in the pipeline that stops it from working as expected.
I have submitted a case, because for me, I need to know the origins of the bug. It's costing me a lot of time and effort.
And for me, building products is all about efficiency. In order of time/effort to create and maintain, my order of preference for this type of functionality is:
1. Build it as a State Trigger event
2. Build it as a condition within a Trigger event
3. Build it as a Trigger event based on a variable
Cheers.
Hi Tim,
I have also had this issue for some time. It started when I updated some SL2 files to SL 360. I gave up after many hours of trying to predict why. I now use variables instead of states of objects on the base layer when the slide contains layers. The problem has now become impossible to predict in Storyline 360 as the output from previous versions cannot always be replicated in the later updates.
Thank you for narrowing the issue down and trying to have the issue resolved.
Regards Doug
Thanks Tim for submitting the case. I see that Renato has been assigned to your case and he'll be taking a look soon. I'll follow along as well.
Is there any new information on this issue? I ran into the same problem last week and spent a few hours trying to figure it out before I found this discussion.
I was having issues with both state triggers and variables working intermittently on certain slides. The project was upgraded from SL2 to SL360.
I was also able to replicate Tim's issue with variables not working as expected on slide layers. When I created a trigger on my second, third, and fourth layers to add +1 to the count of a variable the interaction would not work properly. I finally figured out that for some reason it was adding +2 each time. When I moved the triggers to the base layer they worked properly and only added +1 to the count variable.
Thanks Jamie
Hi Jamie! I just wanted to clarify; you had mentioned that you replicated Tim's issue, and his original issue was that state changes were not working on the slide layers as expected. He used variables as a workaround.
It sounds like you are having an issue with variables not aggregating properly when triggered from a slide layer. Do you have a .story file that you can share? Is this only happening on projects that are upgraded from SL2 to SL360?
Thanks for the extra info!
Qw,
Your use of variable in the conditions solves that problem perfectly.
