Blogging and experimenting is such a competition sometimes – thats why on the team we need to call shotgun sometimes on who is blogging what

First – I couldn’t agree more on the chart/grid/this and that control.

I love the extension method idea… It shouldn’t be too difficult as my fluent interface already has the “jQuery” style object being passed around. The beauty is that DependencyObject could probably be extended to get things moving on any object.

Move, Fade, etc.. all the favouries… love it.

A while back on OzSilverlight I wrote about the third party ecosystem and how the exciting vendors wouldn’t be thinking about grids or charts, but of transitions and animations and layout and navigation. What you have above is very inspiring and really shows the capabilities of SL as a framework. Awesome job. Great idea and nicely executed.

I’d love to see you take this to the next level. I think you could reduce the syntax and make it even clearer. Instead of creating the animations by their type, perhaps focus on real-world abstractions?

For example, instead of constructing the AnimationChainManager directly, you could use an extension method to initialize it, and create simplified extensions that build on the framework you have above. It might look like this:

myImage.Grow().To(300, 600).Over(1.Second()).Begin();

This would deduce the type of the element, add a scale transform/transform group if it didn’t already exist, and setup the animation.

You could then couple this with a jQuery style way of managing events. For example:

myImage.OnClick(m => m.Grow().To(300, 600).Over(1.Second().Begin());

Groups themselves could be an implementation detail. For example:

myImage.Grow().To(300, 600).AndAlso.FadeIn().Then.Wait(3.Seconds()).Then.FadeOut().Over(1.Seconds());

“AndAlso” would group the animation on the left with the one on the right, and “Then” would begin a new group (as I don’t expect you would have nested groups?).

I really like what you’ve done here, thanks for sharing.

Paul

I hope my tweet caused no offence

Fluent API’s are very cool I agree – for a developer like myself I love being able to quickly whip up dynamic animations.

One of the features I love about my framework is end of animation callback which I can then Lambda in another animation. I’m about to post a little article on using a newer version of my lib to make a snow like effect. Each time a flake reaches the end of its animation, the callback ransomises another animation.

Also I have automatic chaining: you can ask animations to queue up, run simultaneously etc.. you can also tell new animations to wait until current anims end, or clear out existing running animations and automatically hand off to the new animation.

I subscribe to your blog and have been following Silverlight.FX – I’ve not had an in depth play however… next I get a chance I shall

Cheers,

Jordan.

I’ve been working on a general purpose procedural animation framework for a while (I ported my javascript framework from couple years back to Silverlight). I used that to build declarative effects and transitions.

Daniel then saw it and we discussed building a fluent API on top of the same core (http://www.dimebrain.com/2008/12/composing-animations-with-silverlightfx.html). No doubt there is similarity, and I think you’re both coming from the same perspective.

You might be interested in checking out Silverlight.FX as well – the core framework I am building. If you do, I’d love to hear what you think…

Anyway, certainly cool stuff!

This is pretty sweet. Nikhil posted about something similar http://www.nikhilk.net/Entry.aspx?id=216 thought you might be interested