Beta 2 - Effects not stacking

Beta
#1

Hi guys, this may well be user error as trying to figure out the effects, also this is within a global block

I have a starting opacity of 0.5 and an x location of -100px
on scroll, I was the opacity to go 1 and the x location to be the default 0

what happens is the x locations works, (although I’ve not been able to get the delay to work) but the opacity stays at 0.5

Beta 2 - effects... some weird sh*t going on here
#2

Hey, @scotbaston!

Thanks for writing in! So I know part of this is due to the fact that we don’t really have the docs up yet on the Effects module, but there’s a little nuance to using it. Effects can stack, but it depends on how you’re using the module. For instance:

  • If you plan on using just an interaction style, then you can additively build on the Base and have the Interaction styles work on that. For example, let’s say that you wanted your button to start with a skewed appearance and 0.5 opacity, but then you wished for it to rotate and skew some more in addition to going to 1 opacity on interaction, you could do this by stacking these two sections together.
  • If you plan on using scroll styles at all, then you can effectively ignore the “Base” section and just use Scroll section. The reason for this is that the “In” styles in the Scroll control group effectively serve as the “Base” styles when that is enabled. I was not able to recreate your exact situation, but I’ve set it up in a way so that when “Scroll” is enabled, it should essentially overwrite and ignore the base styles completely when “in” to avoid this exact setup. All that being said, if you want something to use a scroll style, it is best to just leave the “Base” styles completely stock and to setup your in / out styles in the Scroll group as desired.
  • You can add interaction styles on top of a scroll style, you just need to be careful with how you stack them in some instances. For example, if you want a button to fade in from left like you’re doing on scroll, and then translate up slightly on hover, you should setup your scroll style and interaction style to use transitions, rather than mix and match animations with transitions. While this can work in some instances, it’s best to stick to using the same type in both if you plan on stacking.

We thought about initially setting up the module so that the “Base” style was always the “in” style and if you opted into scrolling you could just add the “out” style on top, but as we played around with it more, we didn’t like the fact that we were constantly changing our base if we decided to opt into a scroll pattern. With this method, you should be able to set a base style, but then if you opt into scrolling, the “in” style of that should overwrite your “Base” styles, allowing you to quickly A/B the differences and decide what you like without having to constantly change multiple values to switch back and forth. As I mentioned previously, the Scroll “in” styles should overwrite your base setup, and I was not able to reproduce your exact situation on my end, so any details you have on that would be great so I can try to see that edge case and eliminate it if there’s something there.

As for the delay, that is working on my end…perhaps if you have any more information to shed on that I can look into it some more, but you can see from this exaggerated example below that I have my button fading in from left on scroll and I have the behavior set to In / Out so that it triggers every time it hits the appropriate offset point. Notice that my transition is 300ms and my delay is a very exaggerated 2000ms. The delay does not take place until an offset is hit. So your element must first hit the trigger offset, then the delay kicks in, then the transition kicks in:

Let me know if you have any further questions on this or if you feel something is off and I’d be happy to take a closer look into it!

1 Like
#3

Hey Kory,

Thanks for all that… it definitely makes things a little clearer. I’m going to go away and play to see if I can create a working version of what I was trying to achieve and alos to replicate the problem I faced

As for the delay… sorry that was a numptie error on my part…

#4

@kory, I can’t wait to get some time to dive into the interactions. Unfortunately, I still didn’t, so please forgive my question if it was supposed to be obvious:

Will it be possible to combine scroll interactions in the way that an element first moves into the position, and once it assumes it, it starts doing something else on scroll, like rotating for example? Or as another example, to change direction of the movement on scroll?

Thanks!

#5

@Misho, no problem at all. I’m always happy to provide more information on anything. :slight_smile:

At this time, the Scroll control group of the Effects Module is based solely around waypoint triggers. This effectively means you have your “in” state and “out” state, and then depending on the behavior (i.e. fire once, reset, in-and-out…) you will pair these with offsets based on the viewport when these states should be triggered. We did consider something like you mentioned above, but what you’re discussing really starts getting into highly complex timeline management of multiple things. It would require a lot more time and engineering to figure something like that out. It’s not completely off the table, but it’s definitely not part of this cycle.

The goal here was to give as much flexibility as possible while not going too over the top with options and management, as what you’re discussing would be highly advanced and require a lot of time and nuance to get right (from a user’s perspective, much less our end in creating the controls and UI). The main goal here was to give back the “fade in column” feature of classic rows, but on steroids. With the ability to specify custom transforms, utilize pre-made animations, and pair all of that with CSS filters / opacity, and then be able to specify a custom “interaction” (i.e. hover) state on top of that, we were able to achieve that, I feel. While we’d love to at some point explore what it might entail to do what you’re mentioning, it’s also a tremendous undertaking, and there are lot more “meat and potato” things at the moment that we’re wanting to knock off our list of features (i.e. responsive styling, revamped base level theme options, et cetera).

Hopefully that helps to provide some context for things. Thanks!

1 Like
#6

@kory, thanks for your explanation!

I got a chance to play with the animations and they are very well thought out.

I have just two things to add:

  1. I haven’t seen a way to trigger an animation while working on it, other than toggle some options, like the Type and Behavior. I think a trigger button would be very helpful. Also, a loop preview would do a lot. Sometimes when playing with numerical values, it is great to see an animation infinitely looping.

  2. I have tried to create a subtle fade-in from left on scroll. I wanted an animation to start closely to the destination, but it was starting from the outside of the viewport. Same for the other similar types. Unless I have missed it, it seems to me that the starting distance in pixels could add a lot to these animations.

Thanks!

#7

Hey, @Misho!

Thanks for writing in!

  1. We definitely have some thoughts on getting in a few features for making working with the effects a bit easier. I mentioned these on another thread, but they effectively involve a few different pieces. One would be a toggle to globally lock all elements with effects in one state or the other (i.e. “in” or “out”). This would allow you to just work on styling the end point of an element in either state, and then preview the transition later. Second would involve some type of “retrigger” button that allows you to preview animations as needed without having to change a setting to see it retrigger. I think this would be better than infinite looping as that could get very taxing on your browser as time goes on, especially with lots of things happening all at once potentially, but a manual retrigger would be very helpful here I think. Not sure when these will get in at the moment, but we do have some plans for them!
  2. When using the transitions on scroll, remember that you have the option between the pre-built animations or something a little more custom with transforms. There is a tradeoff here: while some of the animations might feature more complex movement and chaining of events, it might not be exactly what you’re after in some instances. For example, I believe the “fade in…” transitions from animate.css basically have two variants: standard and big (or whatever they call it, haha). Standard effectively starts translated out 100% of whatever the element is and comes into a 0, 0 coordinate. With transforms, 100% translation means “100% of the width / height of the element itself,” so if you have a very large element, this transition will appear “bigger” while smaller elements will not move as much. The “big” fade-in pre-built animation basically always fades in from fully off screen. All that being said, if what you’re after is a very subtle “fade in from left” where maybe all elements translate in only 5px or so from the left, regardless of their size, in that case you will want to use the Transform option, where you can custom design your own transforms for the “in” / “out” state. In this case you can fine tune the transforms for both states as you see fit, you just lose the ability for the more complex chaining that some animations give you.

Hopefully that helps to give a little perspective on things!