With Silverlight 1.1 (2.0 in the future), the holy grail of developer / designer interaction is infeasible (with WPF it is perfectly possible).
Even when it is possible, there is a mindset which will need to be instilled to make this sort of progression.
The holy grail is to be able to hand over as much of the design (to the designer), so the developer can work on backend code and leave the designer to be responsible for design changes. The real trick is giving the designer the ability modify the UI without impacting/annoying the developer (and vice versa).
In the Silverlight 1.1 (as it is), if for example you wished to change the color of a textblock in a mouseover. UI code will endup in your codebehind, which will be interlinked with the design. If the designer makes a change to the color (or decides to use LinearGradientBrush rather than a SolidColorBrush), the developer will have to change his/her code. As developers (in a 2.0 world), we will have to change our mindset to allow good interaction.
UI Code such as this must be kept within the XAML layer (and not invade the codebehind). We will be able to do this by using techniques used in WPF such as styles and routed events etc.
Once the 2.0 beta is released, this area should definately be revisited, so developers can avoid these mistakes from the outset.
Subscribe to:
Post Comments (Atom)
3 comments:
Very nice point, i too have found this to be the case.
Great point about anything that impacts the look of the UI should stay in the UI. That is so valid and it's something that will cause confusion for developers in the the early days.
Looking forward to styles and routed events.
You can get a bit closer to this, by doing all of your color changes, etc. in the Storyboards, and then just have enough code to kick off the mouseover event. As long as the name of the mouseover event stays consistent, you can change its behavior without changing the code.
I agree that routed events and triggers will make this a lot better, but you can get some level of separation at this point with this method.
That is a great point Bill and is a good little method to workaround these issues today.
However I suspect that most people won't think of these little tricks (and they only work in some instances).
With more complex examples such as the designer decides to change the color change mouse over to a videobrush mouseover. On mouseover the designer wants to play a small section of video in a loop, resetting the video on each new mouse over. Silverlight 1.1 doesn't easily lend itself to these situations.
My point is that is that when Silverlight 2.0 beta is released. Developers should be encouraged to have good UI seperation (with respect to working with a designer), and not go down the wrong (easy) path.
Post a Comment