Revolution! Let's get rid of the EaseVisualizer ..–

[katerlouis]

Hah! Clickbait– What I really mean:

Let's try to need the EaseVisualizer only for the actual visualization rather than as CheatSheet for the naming.

 

https://greensock.com/forums/topic/13388-steppedease-to-step-immediately/

The conversation started elsewhere and deserves it's own thread in my opinion.

 

What is it with ease names? The concept feels pretty inconsequent– I almost always have to look up the names in the ease visualizer. "Was it ease: Stepped.config() or was it ease: SteppedEase.config()? It's ease: Power2.easeOut– but then again it's ease: RoughEase.ease.config()"

Woooh so many combinations where to put "ease" and where not

 

 

Before I start:

I believe there are good reasons behind why you handle the easing calls the way you do. I haven't looked at the SourceCode and woulndn't understand it, anyway. GSAP is all about making things more convenient and therefore some things even possible for the developer. I'm a GSAP user. And from the user-perspective I can say: The easing naming concept is really confusing, kinda inconsequent and arguably misleading.

 

What I want to do here: Point out where the concept has room for improvement – Plead my case and suggest alternatives, hopefully convincing the Elders to implement the ideas. Let's start.

 

SteppedEase

& RoughEase

GreenSocks reason to add "Ease" to "RoughEase" is that "Rough" alone doesn't indicate clear enough as an ease. But Power2 also doesn't shout in your face "I'm an easing!", right? Plus: Rough gets called with "ease: " beforehand anyway (correct me if I'm wrong) and therefore is more than clear to me. I mean; I'm writing "ease: " – What else is gonna come next if not an Ease?

 

Even worse: The confusion you try to prevent, ultimately creates even more confusion, because SteppedEase and RoughEase are the only ones with an additional "Ease" in the object name. That leaves the user wondering "wait, was this the one with Ease at the end or not?"

 

Furthermore: another .ease is required upon call, followed by a .config().

.easeOut, .easeIn, .easeInOut make sense to me and are definitely necessary. But since RoughEase only has the option to ".ease" and you need the .config anyway, why not just skip the .ease part and go straight to the .config? You already agree with me, because SteppedEase doesn't require an .ease. (just like CustomEase also doesn't)

 

Power0.easeNone

Power0 is consequent inside the "PowerX-world" and should stay supported. But I argue most users associate the desired easing with the word "Linear" which GSAP should add support for like "ease: Linear" (again since Linear doesn't take options, no additional .ease or even .easeNone is needed.) 

 

Although I know that linear easing still is an easing, but the users mental model may be that linear easing is no easing at all; so users would like to "disable the easing" > therefore I suggest adding a shortcut like "ease: none" or "ease: false"

 

 

To consolidate the concept even more I suggest reordering the Easings in the EaseVisualizer, leaving us with the following, reordered, list of possible values for ease:

 

// The Go-To guys 
Linear || false || none || 0 (+ legacy Power0.easeNone)
Power1.easeOut / .easeIn / .easeInOut
Power2.easeOut / .easeIn / .easeInOut
Power3.easeOut / .easeIn / .easeInOut
Power4.easeOut / .easeIn / .easeInOut

// Some other "normal" eases
Sine.easeOut / .easeIn / .easeInOut
Circ.easeOut / .easeIn / .easeInOut
Expo.easeOut / .easeIn / .easeInOut

// going beyond the declared value
Bounce.easeOut / .easeIn / .easeInOut
Back.easeOut.config() / .easeIn.config() / .easeInOut.config()
Elastic.easeOut.config() / .easeIn.config() / .easeInOut.config()

// crazy config only eases 
Rough.config() (+ legacy)
SlowMo.config() || SlowMotion.config() (+ legacy)
Stepped.config() (+ legacy)

// Custom
Custom.create()  (+ legacy)

_

 

As much fun as GSAP brings to animating; fiddling with the easing is by far the most annoying thing in the process and I often catch myself thinking "naaah, I'll do the easing later" – That is sad; because what makes an animation truly amazing, believable and immersive, is correct easing. And if you want a perfect result I believe you need explicit easing for every tween.

 

I'm sure you wizards know some magic to give the easing objects multiple names, leaving old code working.

Nobody says "kick SteppedEase"! But provide a better alternative and from now on only propagate these new names.

 

Closing argument:

Even if the implementation would result in 4 more KB, users will benefit from it worth 200PB!

More intuitive naming, writing the code faster, less fear of easing; all this results in more focus on the easing itself and therefore the actual animations, not wondering about what it was named, how to write it down or even worse: leave the editor and search the EaseVisualizer tab.

 

If this wasn't enough to convince you.. 

Surely you'll listen to Shia–

 

 

Sincerely,

 

René from Kreativzirkel

 

 

 

BONUS

For the sake of writing even less as a developer, I throw the question in the room if it is a good idea to make the ease-direction optional with .easeInOut as a default.

 

SUPER
BONUS

Since I find spend roughly 89% of my day on the ease visualizer, I'd say if you want to go full on "whatever the users might remember": It would be nice to support uncapitalized easing objects aswell, same for .easeout etc.

 

MO-MO-MONSTER

BONUS

.Out and .out work aswell

[Shaun Gorneau]

No matter where this conversation goes ... I would like to note that this is one of the most entertaining posts to date

 

MO-MO-MONSTER BONUS ... lol

[OSUblake]

You can alias stuff...

var slappy = Power0.easeNone;

TweenLite.to(foo, 1, { x: 100, ease: slappy });
TweenLite.to(bar, 1, { x: 200, ease: slappy });

Log this out, and explore some of those objects. You'll start to see how the naming convention works. Most of the eases are just aliases for something else.

console.log(window.com.greensock.easing); 

.

[GreenSock]

Thanks for the thoughtful suggestions. It is admittedly difficult to pick names that everyone agrees are most intuitive. Like I said, most of the eases are named that way for legacy/consistency reasons (Penner). If I could do it all over again, I'd certainly name things a bit differently. For years in the Flash days, I had no idea what the heck Quint was or how it differed from Quart or Sine or Expo. Maddening. 

 

That was one of the reasons we built the Ease Visualizer to begin with - to make it easier to understand and visualize. 

 

I have also found that you need to be very careful about choosing short Class names that might be construed as something else. For example, you suggested "Custom". Someone might have no idea what kind of custom thing it is. Custom tween? Custom element? Yes, you're used to typing it right after "ease:" which of course makes more sense in that context, but classes aren't always used in that context. It could also collide with the namespace of other tools. 

 

And of course I'm extremely sensitive about breaking legacy code. Something like 3,000,000 sites are using GSAP now, so imagine if you're a huge company that leans on GSAP heavily in various apps and then they update GSAP and BOOM, suddenly things break. Nightmare. Even if we duplicated things to continue supporting legacy stuff, the new names could create a conflict and it also adds more kb to the core. That's a very tough pill for me to swallow. I get very protective of file size, so whenever we expand it, the cost must be offset by significant benefit. Making the easing names a bit more intuitive to your liking doesn't seem like it's a weighty enough upgrade, especially because you could alias things however you want, just like Blake said. That'd be super easy for you to do. Name things whatever you like Zero cost to the rest of GSAP users and no broken legacy code. Yay!  

 

Another challenge is that if we start providing a bunch of different ways to refer to the same things (Power1.in, Power1.easeIn, Power1.easein, Quad.easein...), it can get even more confusing for people as they start encountering code from different developers who have different preferences. "Wait, what's Power.in? I thought it was Power1.easeIn...was I doing it wrong?" and then it gets sloppy and we get committed to forever supporting all these different options to point at the same thing. API clutter. Kb bloat. 

 

But seriously, I do appreciate the suggestions and I'll keep them in mind for a version 2.0.0 of the platform (when people would expect breaking changes). I do think the easing options could use some reorganizing. 

 

Happy tweening!

[Dipscom]

Rene,

 

In a personal level, I like your suggestion and would agree with many of your points. But, at the same time, I am acutely aware of Jack's positioning and predicament so, I can understand his side as well.

 

I've worked with those eases for so long that I'm used and they make sense in my head. Still, I like your suggestions and would nudge the mighty powers to consider it in a major revamp of GSAP.

 

Just might not happen next week...

 

As other have said, nice attitude to make suggestions. Keep it up.

[PointC]

I’ll drop my two cents worth into this conversation. I would go the opposite direction and say we don’t need any additions to the built-in eases nor would I suggest any changes to the current naming or syntax. 

 

Why? We now have CustomEase and it is a mind-blowing game changer. I spend a large portion of my day in the After Effects and Cinema 4D graph editors so the addition of CustomEase and the Ease Visualizer was like a dream come true to me. 

 

GSAP was already an incredible platform, but now with CustomEase, any old limitations are gone. Throw in CustomWiggle & CustomBounce with its perfect squash and stretch and you’ve got several of the principles of animation covered. Squash & Stretch, Anticipation, Follow Through, Slow in/Out, Timing and Exaggeration have all been made so much easier with CustomEase.

 

It is an understatement to say that proper easing is one of the most important (if not the most important) aspects of animating. I would never leave it until last because each piece of an animation is dependent on the feel & life of the others around it and you can’t bring life to any piece without easing. Learn to embrace it and make it part of the process rather than an afterthought. Once users have learned the GSAP syntax, I think easing should be the next thing that everyone needs to know about making beautiful and believable animations. 

 

To my original thought:

1. I would not change any names or syntax. With so many sites already running GSAP, as Jack said, that would cause a crazy amount of problems. There will always be those who don’t think a name is appropriate or intuitive, but personally I couldn’t care less what an ease is called. Just understand how it works and, as Blake suggested, use an alias if you don’t like something. It’s not like there are hundreds of them so you’ll probably memorize most or all of them after a few uses. You’ll be surprised how quickly they stick in your head.
    
2. But my best advice for everyone involving easing would be to embrace creating your own with the Ease Visualizer. Yes, you will certainly use the built-in named eases for many projects. I use some of my favorites daily, but I’m also building and frequently using my own catalog of custom eases. When it comes to bringing life to an element that animates from point A to point B to PointC (Ha!), you can’t beat a CustomEase. 

I’d say stop worrying about built-in eases and promote the heck out of CustomEase and the Ease Visualizer. Once people understand how to look at and edit a motion graph (it’s a skill every animator should have), they will understand how powerful this is. It truly is an animation game changer and can’t be done this easily with any other platform. Take that CSS keyframe animators!

 

If I were to offer one suggestion involving the eases it would be a slight modification to the Ease Visualizer. We currently have a ceiling area for dragging out the overshoot of the curves which is great, but it would be awesome if there was a sub-floor area to drag out the anticipation of the ease curve. Anticipation is one of those things that’s easy to add, but it brings so much life to an animation so I think it would be cool if it were obvious that you can drag below the floor. 

 

You can see in the screenshot that we can already drag out an anticipation section of the curve and it works fine, but it’s into the copy which is somewhat distracting.

 

My two-cent opinion is now ended. Happy tweening and easing to all.

 

[GreenSock]

Great feedback, PointC. I see what you mean about the area at the bottom of the Ease Visualizer for anticipation. The main reason I didn't expand that is I was worried it was already getting clunky/tall/awkward with the expansion up top (which is used far more often) - I was worried it be weird. Plus it'd shove the green line on the left up, separating the x/y axis. Not the end of the world, just a little clunky. And all the code gets pushed down. I dunno - it's probably worth doing anyway but I wrestled with it. 

 

I'm working on some other stuff at the moment, but when I revisit the visualizer next I'll definitely consider making this enhancement especially if others echo the request. 

 

Thanks again for the excellent feedback. 

[PointC]

Yep - I see your point.

 

That could get a little too tall for some screens with an anticipation area. It's not really that problematic the way it is now. I just don't know if everyone using it realizes that you can drag below the floor.

 

Thanks.

[katerlouis]

Like I care if you change a thing; the only reason I wrote that post is to dive deep into the easing names and learn them by heart. I'm right and I know it- pff.

 

.

TweenMax.to(me, .1337, { seriousMode: 1, ease: Linear })

.

 

It is an understatement to say that proper easing is one of the most important (if not the most important) aspects of animating. I would never leave it until last ..

 

.. Learn to embrace it and make it part of the process rather than an afterthought.

 

I totally agree with you!

But I am not a full time animator and honestly kind of struggled with the mental modal of easings at the beginning. Surely there are others that felt the same way. Just like you, I want the web to get richer in meaningful and immersive animations. And I am also truly amazed by what GSAP can do and how easy it is makes it to do it. And that's exactly why I took the time to tackle its (for me) biggest weakness in terms of "dragging non-animators-and-not-so-skilled-developers on the dance floor", convincing them that all these stunning CodePens are only cooked with water. If a clearer naming concept could help some people here, why not change them?

 

 

 

Another challenge is that if we start providing a bunch of different ways to refer to the same things (Power1.in, Power1.easeIn, Power1.easein, Quad.easein...), it can get even more confusing for people as they start encountering code from different developers who have different preferences. "Wait, what's Power.in? I thought it was Power1.easeIn...was I doing it wrong?" 

 

That's why! Didn't think about that. Total deal breaker for my request. Absolutely agree.

In the codepen-stackoverflow-forum-docs-slack-world this is sheer poison and clearly counterproductive to what I am trying to achieve with this.

 

But I still hold on to my argument that really amazing results or maybe even the believe in being able to handle really complex, big animations, require fully internalizing all of GSAP, easings in general, GSAPs easings, what they do, how they play together, and especially their names. GSAP isn't a closed environment like After Effects (forget Plugins, please! ) – GSAP usually is an addition to a probably already complex webbing of dependencies.. CMS output, CSS methadology concept, maybe crazy React/Ember/VueJS4/AngularSSJ3/Nasa-MissionPluto.moon.js framework, which isn't necessarily second nature to everybody.

 

And when a more intuitive and consistent naming could help even some people to dare to jump into animationLand, or just visiting the visualizer less frequent, I think it's worth a shot at some point in the future.

 

 

The sole argument "who cares what they are named; just learn what they do and you'll be suprised how quickly you'll remember the names" just isn't enough for me, and doesn't pose a reason for not changing the names. And I think it's not enough for GSAP aswell. The whole reason why I get so invested in this community, typing 1.5 hours on a single post, is GSAPs obvious hunger for perfection; trying to marry convenience, execution performance and lowest possible filesize– this spirit flows through these four letters and infuse and infect people to tween their butts of; I want it to be razor sharp wherever possible, so all my muggle friends stop fearing easing and go find themselves a wand! 

 

 

 

So you convinced me to drop my weapons (for now >8))–

But how about reorder the list in the ease visualizer?

(Cmon! Gimme something here–)

 

 

 

René

 

 

PS:

GreenSock, I like the overprotective father; but your babygirl has grown and prom will be there faster than you know.

Gimme a call when you start 2.0.0 and we make GSAP great again! (too harsh? Who cares.. I'm from Germany)

 

 

PSS:

btw.. I still have not the slightest clue what the word "Tween" means, where it comes from or why it is fit to describe an animation. I was highly confused by it at the beginning– so much actually, that I skipped on GSAP twice. Now I just accepted it as vocabulary and learned what it stands for

 

.. you and your names–

[PointC]

I get the feeling that you took some offense to my post. It certainly wasn't meant as such and if it felt that way to you, I apologize.

 

I started and ended it with 'this is my two cents worth' so you can certainly take it or leave it. I also said 'I personally' didn't care about the ease names. That doesn't mean you shouldn't care. I do stand by my advice about renaming with an alias rather than asking for a change to the platform. It's simply the easiest thing to do for anyone not happy with the names and is completely customized for you.

 

Yes, learning easing can be difficult. I've worked with and trained other animators so I've seen the 'we'll add the ease later' attitude. Moving an element is technically the animation, but the easing is what makes it great. That's why I said learn to embrace it as part of the process even if it's hard and you have to adjust it over and over. It's part art and part science, but it's what gives life to the motion. It will become second nature in time.

 

I do wish you the best of luck in your learning.

 

Happy tweening.

 

PS Tween is short for in-betweening. Meaning the movement that happens between keyframes.

[OSUblake]

A tween is a 12 year old. 

 

I'd agree with PointC by saying that the built-in eases aren't worth worrying about anymore. To be honest, I really don't know what most of them will do without looking at the ease visualizer. And if I'm doing that, I might as well just make a custom one. The custom eases are also faster, so that's better for performance.

 

And did you look at that easing object in the console? There's already too many different names....

 

 

 

 

And for the special eases, you can use the constructor instead of the config/ease.config methods if that's too confusing. That's all the config method does behind the scenes. 

var rough = new RoughEase({ strength: 1, points: 25, taper: "both", randomize: false });
var slowMo = new SlowMo(0.5, 0.8);
var stepped = new SteppedEase(5);
var standard = new CustomEase("", "0.4, 0.0, 0.2, 1");

var tl = new TimelineMax({ repeat: -1, yoyo: true })
 .to("#box1", 2, { x: 400, ease: rough }, 0)
 .to("#box2", 2, { x: 400, ease: slowMo }, 0)
 .to("#box3", 2, { x: 400, ease: stepped }, 0)
 .to("#box4", 2, { x: 400, ease: standard }, 0);

See the Pen b03046de7df5ca7e3dcf2aa6b98e9cd1?editors=0010 by osublake (@osublake) on CodePen

 

.

[katerlouis]

There are always workarounds and thousand ways to Rome. 

My point remains: it took a lot of digging to find out about the other names seen in the object.

We can't expect new users to have the endurance, stamina and motivation to dig so deep into Easings right after they first load up GSAP.

 

I just learned that CustomEases are better in performance? And you just agreed that you can't work without the EaseVisualizer at all. Easings are already hard to grasp by nature and even harder when you are overwhelmed by GSAP alone – This is circumventable and worth making as intuitive as the timeline concept is. 

 

That's all I'm saying

 

 

The code example of OSUblake got me thinking;

is it better performance-wise to create an easing with `new RoughEase`, store it in an var and use this instead of rewriting the same RoughEase multiple times?

And if the performance is better; how much better are we talking here?

[OSUblake]

The code example of OSUblake got me thinking;

is it better performance-wise to create an easing with `new RoughEase`, store it in an var and use this instead of rewriting the same RoughEase multiple times?

And if the performance is better; how much better are we talking here?

 

Yep. Caching an ease in a variable is better for performance, but you won't probably won't notice a difference unless you're animating thousands of objects.

 

Also, storing an ease in a variable makes it easier to quickly change out and test out a different ease for multiple animations. This is what a lot of my code during development looks like. A bunch of commented out eases, trying different variations...

// var myEase = Power1.easeOut;
// var myEase = Power2.easeOut;
// var myEase = Power3.easeOut;
var myEase = Power4.easeOut;

var tl = new TimelineMax({ repeat: -1, yoyo: true })
 .to("#box1", 2, { x: 400, ease: myEase }, 0)
 .to("#box2", 2, { x: 400, ease: myEase }, 0)
 .to("#box3", 2, { x: 400, ease: myEase }, 0)
 .to("#box4", 2, { x: 400, ease: myEase }, 0);

.

 

 

And you just agreed that you can't work without the EaseVisualizer at all. Easings are already hard to grasp by nature and even harder when you are overwhelmed by GSAP alone – This is circumventable and worth making as intuitive as the timeline concept is. 

 

That's all I'm saying

 

I know what you mean. But I think instead of improving the names, the tooling should be improved. Remember that QuickSettings

See the Pen 1d41e4a147b32a0de8dd934cbeebc10b?editors=0010 by osublake (@osublake) on CodePen

? That's what people need. A way to interact and change an ease in real-time through a gui.

 

If I had time, I'd make something that works like this...

 

 

.

[GreenSock]

Just to clarify on the performance comment, CustomEase does a bunch of calculations up front to make runtime performance smoking fast (essentially creating a lookup table of sorts), so it's actually more costly up-front and then at runtime it's moderately faster than only some of the eases. For example, it's faster than Elastic, but I don't think it's faster than the standard Power* eases. Honestly the difference is negligible. You'll never notice a difference. Even with hundreds of simultaneous tweens. MAYBE if you've got 5,000 Elastic tweens there's a chance that the CustomEase version of that would be very slightly faster visually than Elastic in particular. Even if the CustomEase is 2x faster than Elastic, the easing is only a small part of the overall performance profile, so it might ultimately be only 5% faster overall (MAYBE). 

 

But it's DEFINITELY faster to reference the same ease instance over and over instead of creating a new one for each tween, as Blake recommended. That'd be noticeable, especially for CustomEase. 

 

I just didn't want you to get the impression that it's somehow bad or slow to use the standard eases. Not at all. 

[katerlouis]

Good thank you;

 

OSUblake; this .. video is .. amazing!

But isn't that blasphemy? Why aren't we all using mojs instead!

 

The Syntax looks bluäääh, but this workflow- woooh.

Okay, how can I help to make this happen with GSAP? :>

[OSUblake]

Yeah, I probably shouldn't have used performance as selling point for custom eases. Just know that everything in GSAP runs fast.

 

 

OSUblake; this .. video is .. amazing!

But isn't that blasphemy? Why aren't we all using mojs instead!

 

 

Funny. Mojs is kind of what got development of the custom ease to speed up. See this thread. Notice how Jack didn't have time to work on it in the beginning. So I made a couple prototypes, and then like a week later he had a pretty solid version of it working.

https://greensock.com/forums/topic/14810-easing-feature-request/

 

So I wouldn't call it blasphemy. Just planting seeds. Plant the right one, and a week later it might bloom.

 

And yes, mojs does have some really nice looking features and demos, but I don't think it's ready for production. It doesn't get updated that often, and the developer just got hired by Microsoft, so who knows if he'll still want to work on it as much.

 

.