JavaScript Animation and Browser Scaling
Nov 20, 2019
Hello,
First time poster, long time reader. I first want to say thank you for your products and hard work. I love building eLearning with Storyline.
Situation: I often use JavaScript to animate objects in Storyline. I have been using it for a while now and have always tested on all device types (mobile, tablet, PC). In previous versions of Storyline, if I moved a Storyline object on the slide using a JavaScript animation, the animation would scale with the browser window relatively. With the most recent update, when I scale the browser, any object that I have moved using JavaScript does not scale with the browser. As a development team, we have used JavaScript animation extensively and this would break a lot of our existing modules if we ever needed to update them. Moreover, going forward it's unclear whether we'll be able to use JavaScript animation reliably at all due to this scaling issue.
Here are two examples. The first example is published from Storyline version 3.25.18009.0. In this version the animations scale with the browser but maintain their relative value to the black line.
The second example is from version 3.34.20804.0. In this example, you'll notice if you resize the browser that the yellow rectangle does not scale relative to the black line. If you make the browser window small enough (e.g., iphone size), the yellow rectangle disappears completely to the right.
Example 1: v.3.25.18009.0 https://360.articulate.com/review/content/a6bdd5c1-c279-4790-bc56-63ca9662b9d1/review
Example 2: v.3.34.20804.0 https://360.articulate.com/review/content/ede15769-5827-4857-9456-1673a3002681/review
This is quite a big issue since many of our modules use this type of animation.
Can your development team shed any light on what might have changed in the most recent update as it pertains to the user manually resizing the browser window?
12 Replies
We are having the same problem.
Hi Justin!
First off, thanks for sharing your kind words about Storyline! We think so too!
Secondly, I'm happy to see you've submitted a case and working with Jopney, one of our Support Engineers! You're in good hands!
I'll be following along to see the outcome!
Curtis, I'd recommend also working with our Support Engineers! Please use this link to share your file and begin troubleshooting.
We were holding off on updating Storyline because of the web object resizing issue. in the mean time we started using JS animations in SL which are now having the issue Justin describes above. How long is it reasonable or possible to keep using this now almost year old version of Storyline?
I am on v.3.25.18088.0
Thanks!
Hi there, Curtis,
I did a little digging, and I found your case from earlier this year where you reported having web object scrolling issues on an iPhone – is that the same problem you're referring to here? The good news is we're prioritizing a fix for that issue!
Oh! that is good to know we will have to make some adjustments here. The new issue is around tweening Storyline objects using the Javascript trigger.
We bring in the Greensock library using a webobject in a child slide.
On the Slide level we get the aria label from the accessibility panel:
var item = $('[aria-label="storylineshape"] svg')
That allows us to then tween that storyline shape using GreenSock:
go();
function go() {
TweenLite.to(item,4,{rotationX:90,rotationY:45,x:900,ease:Elastic.easeOut})
}
This has worked beautifully and we can do some amazing animations directly in storyline without the need for web objects.
What is happening now is we cannot tween things TO and X or Y value. Justin has a great example above. It does not respect the stage being resized any more. That is true of any JavaScript positioning in the x or y not just greensock as Justin is showing above.
We just realized in poking around the published code that Greensock is already in the Storyline output. There are numerous references to greensock and tweenlite in app.min.js. Where and how is GreenSock being used in Storyline?!?
Hi all, we face the same issue. Do you already have a cause and/or solution for this javascript scaling problem?
@Justin Hughes @Alyssa Gomez
Kind regards
Jasmien
Hi Jasmien,
I am glad to see that you opened a case to connect with our Support Engineers! You are in good hands, and our team will be reaching out to share additional insights .
I'll be following the case as well to see the outcome!
Following because i do use GSAP and love it, and would want to extend animation in SL with it...but reading this for sure limits that..
Any solution in SL360 to the scaling issue ?
As i replicated the samples above of Justin to see how to fix it i up till now only found 1 solution.
Using GSAP3, i use gsap.getproperty to get the x of the 'Motion Path' shape and set a variable for anyother shape to move on x.
Like this:
var xPos_MotionPath = parseInt(gsap.getProperty("[data-acc-text='MOTION PATH']","x"));
var shapeToMove = $("[data-acc-text='rect2']");
gsap.to(shapeToMove, {duration: 1.5, x: xPos_MotionPath});
Offcourse this doesn't really solve the issue, especially if on older SL-versions it worked, but at least a workaround for it.
KInd regards,
Math
As i noticed the behaviour mentioned by Curtis and Justin too...making position based animation with Javascript in Storyline tough... i just noticed an update in GSAP that might fix these issues.
https://codepen.io/GreenSock/pen/4c7902f691dd5e2216200e5f14f75071
getRelativePosition( );
Thus converting from some local coordinates to some other elements local coordinates.
I didnot update my Gsap libraries yet, but for sure gonna test and try this...
Here is another possible workaround.
The idea is to get the window size from $(window).width() and $(window).height(), then compare the width/height of the slide with those of the window and multiply the coordinates of the motion path by this number.
Depending on the size of the browser, we should calculate the ratio of the widths or the heights, because of the empty space between the slide and the edge of the window. For the slide 1280x720 without a build-in menu, I found that it should be like this: if the aspect ratio of the browser window < 1.77 => we should use the width, if > 1.77 => we should use the height. But this will be different for a slide with different proportions and if we use a built-in menu.
It works perfectly with the GSAP MotionPathPlugin if we convert compound path to bezier points with snap.svg.
This discussion is closed. You can start a new discussion or contact Articulate Support.