When Blend 2 SP1 was launched along with Silverlight 2.0, I had one problem with it. While the new visual state manager concept was great in allowing designers to define how the controls looked there was still one problem. There was no way for designers to do things like dictate that clicking a button started an animation, or moved to a different place in the application. This means that if you were creating an RIA application, the programmer would first had to create the basic navigational and behavioral skeleton of the application before the designer could start work. And also if the designer wanted to test some simple flow changes it be a bit of a trouble for them to do any changes unless they happened to know a little bit of .Net programming.
If we compared Blend 2 SP1 with Adobe Flash’s development environment, Blend 2 was at a disadvantage because of this. Since there wasn’t any way for a designer to complete their ideas without asking the developer for help. And now.. we have Silverlight 3 along with the RC version of Expression Blend 3. And I’m LOVING IT!
What’s there to love? For one thing, in order to solve the problem I described above I would have accepted it MS would have just written in some more event triggers in Silverlight instead of just having the useless ONLOAD that we had in SL1 and SL2. But MS went above and beyond that. Instead of defining additional triggers, they now allow the DEVELOPERS to create their own TRIGGERS. And instead of defining additional actions to the base elements. The DEVELOPERS themselves can create their own ACTIONS that can be attached to TRIGGERS to make them functional.
Ok, I’m not making much sense without an example. Basically a TRIGGER is an event, it could be something like on mouse click, on mouse move, etc. etc. And an ACTION is well… an action that does something. Let’s explain with the earlier example of a designer wanting to add some functionality to the app they’re designing. For example:- once a button is clicked, start an animation. This was not possible in Blend 2, and in order for the designer to see the results of this effect a developer would have been needed to write the code to wire up the logic. But in Blend 3, the designer would drop a MOUSE CLICK TRIGGER onto the button and then on the trigger he would drop a PLAY STORYBOARD ACTION and set the target storyboard to the name of the storyboard they wanted to play.
But that’s nothing new to Flash users, and I wouldn’t be making it sound like a new innovation if that was just the case. The fun part about this is that because the DEVELOPER can make new TRIGGERS and ACTIONS it means that if the base ones don’t work for the application and logic you require for YOUR APPLICATION, JUST MAKE SOMETHING that YOU NEED!
And the coolness doesn’t stop there yet, other than triggers and actions. You can also develop and drop BEHAVIORS onto your elements. And this is where it gets interesting. A behavior is exactly that, it tells the element it was dropped on how to behave. An example of a behavior is like Drag To Move, Shrink On Click etc. etc. And.. the most extravagant example of behaviors comes straight from the Blend 3 samples. It’s called BeeHive and is essentially a BreakOut clone, but what’s special about it is that the whole game was written by dropping custom game behaviors like collision behavior, movement behaviors, etc. etc. onto simple Image elements and poof.. GAME!
This just makes me wondering.. when creating a SL application (or WPF for that matter) it almost seems as if that I should write my application logic as behaviors so that designers can just drop the behaviors onto the elements which they see fit so they can easily change how the UI looks without going through me.
Wow.. what a long post.. and I haven’t even talked about sample data generation… and SKETCH FLOW! Another time then.