Re: [web-animations] Simplifying timing groups

Hi Mike,

that feature was dropped in the latest version of Flash CC because nobody
used it.
Even if it was still in, the timeline in flash itself is always linear.
Individual items on the stage (which aren't groups) could be tweened by
this UI.


On Thu, Aug 8, 2013 at 4:50 PM, Mike Lawther <>wrote:

> [apologies if threading doesn't work in this reply, sending from right
> account this time]
> Rik points out that Flash doesn't support this and yet somehow Flash
>> authors have managed pretty well.
> Case in point for Flash:
> In particular the bit about modifying the animation of the wheels so it
> matches with the timing function of the car - "You can adjust the value to
> match the ease used for the car (100) [...] Save time by copying the motion
> settings for the front wheel and applying them to the back wheel."
> The authors *want* to be able to apply the same (non-linear) timing
> function to a group of objects, but are stuck manually adjusting and
> copying and pasting them. Note this isn't an entire timeline - but
> manipulating the time of group of objects so they behave as a cohesive
> 'sprite'.
>> Last year in October when we demoed Web Animations we actually used this
>> feature to ease both a door and its creaking sound.
> So there's definitely use cases for doing this - and it only took a few
> minutes to find the one from Adobe I mentioned above.
>> There are two things
>> to note about this use case:
>> a) It could easily be done by applying the timing function to the two
>> child animations independently.
> While I take the point in a) that it's *possible*, having read the above
> tutorial, I'd say 'laboriously' instead of 'easily'. Imagine that car was a
> tractor with a larger rear wheel. Yuck. Motion graphics designers I've
> spoken to spend a lot of time tweaking timing functions - it's how they
> make their magic. After Effects even allows you to write script to control
> animation timing.
>> b) It could *also* be done by allowing a restricted set of timing
>> functions on groups.
>> I'm open to the possibility of adding restricted easing behaviour on
>> groups like SMIL3 offers. I'd prefer to add that later but would be ok
>> with adding it sooner if there is sufficient demand. I think that would
>> address a number of the uses you outlined above without introducing many
>> of the undesirable qualities of allowing arbitrary timing functions.
>> I just feel that introducing features that (a) introduce considerable
>> complexity, (b) are provided by no other animation platform we've found
>> yet, and (c) for which we have yet to find concrete use cases that can't
>> be solved by other means, seems like over-engineering for a first
>> version of a spec. I think we can add this later if needed.
> This is a concern about developer ergonomics - if there are clear use
> cases and it would make developer's lives better, it's the developers we
> should consider.
>     mike

Received on Friday, 9 August 2013 07:12:40 UTC