A big chunk of our everyday prototyping revolves around figuring out how “things” should appear on and disappear from the screen, based on the user’s input. Often times, designing those interactions will require chaining two or more animations to obtain intuitive and meaningful transitions. Harnessing animation chaining will surely improve your design and make it more attractive and user friendly.
Although animation patches let you input any Number to start them up, the most common practice is to trigger them with the Switch or Conditional patches that return 0 or 1, alternately. You can easily make things animate into (1) and out (0) of the screen after being triggered by a mouse click or some simple condition, e.g. the scroll position.
Things can get complicated pretty quickly, though, when you want to launch a sequence of animations using just one event as a trigger. And by “sequence” I mean that they don’t launch simultaneously, but rather wait for their turn. If, on top of that, you want to reverse the order in which the sequence animates in and out, things can get truly awful…
Let’s take a look at the example below.
Two horizontal cells slide in and out from the left in visible order. One way to chain animations like that is to use the Timer patch and connect it like on the image below.
We set the Duration on the Timer patch to match the duration of the first animation. Now, when we click our button to trigger the first animation, it also turns on the Timer. Once the timer is done counting, it triggers the Switch on the second animation and the chain is complete. It’s a simple setup, it works great, and you can set the Timer to any Duration you want.
What if we need to reverse the order of the animation sequence on the second run?
Why would we ever need to do that?
Consider the example below.
These are all very simplistic and generic examples with minimal design, but I’ll bet you already know why the example above doesn’t work. Obviously, the order of the animation sequence during the second run is counter intuitive. The blue “container” square enters the screen, then the white “content” square appears inside. The obvious dismiss/close animation would require the “content” square to scale down first and only after it’s gone should the blue container leave the screen. In some cases, this First-In-First-Out model will not work. Instead, we’ll need First-In-Last-Out.
Such an approach would require reversing the order of the animations during the second run. In the language of the Quartz Composer editor window, it would mean rerouting the animations on the fly by using Switches, Multiplexers, Conditionals, etc. If it already sounds complicated, imagine having 3, 4 or more animations launching in a specific and reversible order…
I didn’t want to do that. Not that it’s impossible, it’s just exhausting and not very reusable.
I came up with a different approach to the whole problem of chaining animations. The examples above were all based on the idea of one animation telling another when to start. It’s like they all know about each other and yell “Hey! I’m finished. You’re next! Go!”
I thought it would make a lot more sense to have one patch that triggers them all so they don’t really care which comes first and which comes later, they only respond to one central patch — “Hey! I’m finished. I don’t know who’s next but tell him to go ahead!”
Behold… The Animation Dispatcher
Well, I had to come up with a name, but what it really is is the Counter 2 patch bundled with some useful logic. I created the second patch to go with it — Chained Animation, which is Classic and Bouncy animations (you can choose one) bundled together with some more logic to work with the dispatcher patch. I won’t delve into the science behind the whole thing, let me just give you an overview of how it works.
What Counter 2 patch does is hold a number. By default, that number is 0. There are a few inputs on the patch, but we will only need two of them: Increase and Maximum Count. The latter tells the patch how many numbers it should iterate through and the second does what it says – it increases the currently held number by 1. So, if we set the Maximum Count to 4, for example, and repeatedly trigger the Increase input, the Counter 2 patch will produce the following sequence: 0, 1, 2, 3, 0, 1, 2, 3, 0, 1, 2, 3, 0, 1, and so on…
We can take that output now and connect it to 3 different animation patches through a Conditional patch, each one expecting different value (Is Equal to 1, Is Equal to 2, Is Equal to 3), we can trigger those animations in a sequence. Also, 0 would be our “holding position”, so that you actually have to Increase (CLICK) the Counter to launch the first animation.
Now, if we add a Logic patch set to OR and let the Increase input be triggered by the Click [OR] by any other logic we want to incorporate in that sequence… well, you probably know where I’m going.
The first animation will increase the number once it’s finished, triggering the second animation to go. Each animation in the sequence will do the same until the number goes back to 0 – our “holding position”.
Reversing the sequence of the animations would be just as easy as “hacking” the Counter 2 patch to produce a different sequence: 0, 1, 2, 3, 4, 3, 2, 1, 0, 1, 2, etc., with 0 and 4 being our “holding positions.”
Now, let me show you how to use the patches.
But before we get to that, let’s have a look at this ridiculously overdone example below:
It works fine until we click the button again. Then it falls apart as the animations follow the standard First-In-First-Out model.
But let me just select the FILO checkbox on the Animation Dispatcher patch and…
Voilà! One click and it works like a charm. And I set it all up in less than 5 minutes!
The approach is fairly simple. You place one Animation Dispatcher and as many Chained Animation patches as you need. The image below shows the connections for two animations.
So, connect the Interaction 2 patch to the Trigger input on the Animation Dispatcher patch.
The Dispatch output should be connected to all animations in the sequence. Set the Chain Length to match the number of animations you will use in the sequence.
The FILO checkbox lets you reverse the order when animating back.
The Index on the Chained Animation patches indicates the order in which they should play. Index = 1 means the animation will go first, Index = 2 means it will go after the first, and so forth.
Animation Type lets you choose between Classic and Bouncy animations.
Dispatch Duration is the time after which the next animation should be triggered.
Connect the Dispatch Next outputs from every1 Chained Animation back to Animation Dispatcher via a Math patch set to + (you can set the number of available inputs on a Math patch in Patch Inspector).
The rest are just familiar settings for the animation itself. Note that there are two separate settings for the Classic Animation progress curve. You can have different a curve for animating in and a different one for animating out.
Feel free to use them and please give me your feedback.
1. If you use two or more animations with the same Index (animating simultaneously), you only have to connect the Dispatch Next output from one of them.