Just read Robby’s excellent post about silverlight templating model.
I will start off by admitting that I think Robby is a ton smarter than I am and his intimate experience with helping to define the templating and styling models for WPF make him a much better candidate to see the big picture of this topic. To add to this… I have actually experienced some of the simplicity the new model in Silverlight 2.0 brings to it and can very much agree with most everything Robby says here. (Triggers and Binding in WPF are enough to get you into a lot of trouble where templates become big messes of “XAML defined logic” and state managed nightmares..) WPF Templates definitely have a steep learning curve for somebody to really learn to harness the possibilities. I think this model is more accessible.
That said, I have already had some painful experience with the developer/designer workflow because of the “not so loose” contracts in Silverlight 2.0 control templates.
Simply my problem resides in the fact that I was working with a large set of developer created controls that defined the contracted elements in each template. Mid stream in the project there was a large change in the project that caused the developer to re-architect a bunch of the controls as well as there was a standards/consistency effort afoot that caused the developer to rename all the elements (you know how religious developers can get about naming conventions … The end result was a mass of control templates that were broken. Sure it isn’t too hard to rename elements… But the real friction occurred because of the communication that was required to decide who is responsible for fixing the XAML for these controls. If its one or two controls its not a big deal… 32 controls with complex internal dependencies on styled controls… it does become a big deal… Why? because a lot of developers don’t know what “right” looks like to fix the controls themselves… So because of the tight contract between the designers design and the developers code it became a two man job to fix the changes.
I feel like this breaks the “holy grail” idealistic plan to create “lookless controls” so designers can work on visuals and interactivity independently of logic and function. Which brings us back to a not very parallel dev/designer work flow pre WPF. Now I have to make sure to sit with the developer and make sure they have thought through all the visual states that a control can be in (which in so many cases I haven’t really understood or uncovered until we get deep into the application development). It becomes a ping pong dev/design workflow rather than a parallel… (of course I still think this is way better than what we had before XAML).
If all we were templating and styling were the stock controls (button, ListBox, slider, etc) then I can see the value of making it easier and more toolable… But I am more excited about creating controls that nobody has thought of before that really advance the state of interactive applications. Reducing the friction of communication between developer and designer by making controls lookless so I can focus on figuring out amazing interactivity that maps to logic/behavior/function that is supplied by a developer still seems more powerful.
Totally a hot button issue with me lately… I think seeing the flip sides of this argument should illustrate how passionate we are at Identity Mine about workflow and roles…
All this said, the current state of templating in Silverlight is light years ahead of anything I have done in competitive platforms we just need some consistency between WPF and Silverlight or a roadmap to consistency…
(oh and what’s with naming elements with dependencies PART_ in WPF and not in the same controls in Silverlight?… I would love it if because I knew what a “part” in a control is named in WPF I would know what the corresponding part is named in Silverlight? Try styling a ScrollViewer in WPF and Silverlight to see the differences)