How do you troubleshoot advanced Storyline interactions?

Hey helpful community peeps...

Creating advanced interactions in Storyline can be tons of fun and it can also be a challenge to get everything "working" as it should. By advanced interactions I mean .story projects that incorporate layers, states, lots of triggers, conditional triggers, variables, animations, etc. 

Awhile ago I wrote this article about troubleshooting advanced interactions in Storyline. It covers a few good things to know about, but since then I've thought of more items that I didn't include in the article at the time, but that are important to know about. So I'm thinking of writing another, even more comprehensive article for troubleshooting Storyline interactions. Here are my tips so far, I'd love to know if you have ideas or suggestions for other things to add to the list. Also if you leave a tip or suggestion it's super helpful if you can explain why, when, and how you'd use it. Thanks in advance community!

  • name your slides, layers, objects, variables with clear & descriptive names (makes setting up triggers, etc. a lot quicker and easier)
  • verify trigger order (it matters!)
  • check your variables (verify the default values, verify they are used in the correct place)
  • check slide and/or layer properties (is the Resume slide option as it should be?)
  • check the timeline (are the objects appearing on the timeline when they should be?)
  • check for animations (Are there entrance or exit animations on your objects?)
  • Create fake buttons you can use for testing purposes (so you don't have to click through the entire interaction during testing, can just click a button to have something happen quickly to test it)
  • Insert references to all variables so you can ensure they are working properly during testing

What am I missing?

9 Replies
Jesse Anderson

This may be what you mean by your last bullet point but I wouldn't get half of my complex solutions to work without the %VariableName% function. Seeing what variables are doing in real time helps to figure out why things aren't happening like you may have expected. 

I also frequently get tripped up by the simple things, like making sure I've turned back on the visibility of items after I've finished making changes to them.

Lastly, make sure it's not a software bug. When something just isn't working like I think it should I'll sometimes dust off an older version of Storyline and try to build an identical interaction there. I found two or three bugs in our transition from SL2 to 360 that I had to report. An interaction would work perfectly in SL2 but wouldn't work at all in SL360.

David Goodman

2 cents:

when in the timeline, use the lock generously and numerously. Things can be easily changed on the timeline.

when you are really stuck and something is not working, walk away and do not think about the problem - clear your mind by doing something else. When you return, you normally have some answers or at least additional options. If your blood pressure is rising, ask someone to help and look at it with a new pair of eyes - do not continue to struggle.

use the Bookmark within this forum and build your own trouble shooting "booklet" with your own lessons learned. keep it up to date.

Zsolt Olaf suggested at our last users group to work out the variables on paper before trouble shooting - visually see what you think you are doing as a confirmation.

Sean Speake

If you're running up against something that's not working as anticipated, open a new SL file and start building the piece from scratch. Don't copy anything over and only refer to the original if you absolutely have to. Frequently you'll find you get it working and then have a solid framework to compare to the original version to see where things have gone wrong.

Be happy to delete something - if I find an animation or state or something is behaving strangely, I'll delete and create a brand new version rather than mucking about with something and trying to figure out why it's not working. I find it saves me tonnes of time.

Phil Mayor

I think it starts at the build stage, I build advanced interactions incrementally and test, test , test to ensure they work. even though they are complex interactions i like to keep them simple stupid, so i can pick back up 12 months down the line.

By building in stages I have created 'functions' that I can switch on and off during the debugging stage, i often create a hidden shape off stage. with lots of triggers  applied on timeline start that I toggle normal/hidden to run the 'function'. For debugging this means I can hide the later functions to see where it breaks down.

The beauty of using shapes is that I can type what each one is meant to do directly into the shape.

When debugging I will move the shapes onto the stage so i can see if the are triggered (I remove the toggle).

Trigger order is typically the first thing I check.

In complex project I create a slide master layer with all my references for the variable values, that is triggered via a keyboard shortcut.

If needed i will spend time in the variable count trying to work out why something doesnt work, especially useful for menus if one variable has a higher use count that is probably where the problem is.

In menus that are locked and unlock progressively i will create a layer that will unlock everything for testing.

I do spend time hiding and unhiding objects on the timeline to make sure i have the correct target object.

I still spend a lot of time smacking my head when things don't work, I try to build everything so it is reusable and can be repurposed elsewhere. I only ever name things that have actions applied to them.

Matthew Bibby
Phil Mayor

In complex project I create a slide master layer with all my references for the variable values, that is triggered via a keyboard shortcut.


This is my approach as well. But for complex projects, I'll also set up a keyboard shortcut that will result in a new email opening containing all of the information usually found on the debugging screen, along with browser info, etc. 

Alexandros Anoyatis

I too echo Phil. I spend extra time in making functionality as "portable" as possible, even though that is not required nor specifically requested by the client.

I have found that the first and most important principle in doing this is to try to keep the presentation and logic layers separate, in order to ensure reusability in other projects. That helps me down the line when I have to reuse part of said functionality.

Trevor Peglowski

Don't forget to also check the order of objects on your timeline. I was making a menu screen for a client once and couldn't for the life of me figure out why someone who completed a module (and therefore had a gray, slightly transparent box over the shape) couldn't review it again. 


Turns out, the hotspot was BENEATH the oval, so it wasn't activating.