Fwd: [web-animations] Simplifying timing groups

[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:
http://www.adobe.com/devnet/flash/articles/creating_animation_motion_editor.html.
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