The BIG Problem with Silverlight's Control Templating Model

Robby has just fired this shot in The Great Templating War Debate of 2008.  I don’t often disagree with Robby on platform issues, but…  I am now compelled to reply with an opposing viewpoint on this issue.

In my opinion, there are several problems with the templating model in Silverlight 2.0. I’m not going to focus on some of the more obvious ones (like the fact that WPF and Silverlight are using completely different models) because I think they have been covered quite well by others.

Instead, I’m going to focus on what I consider to be the BIG problem… Silverlight’s templating model breaks the developer/designer workflow.

The biggest value proposition for both Silverlight and WPF is the workflow that they enable between developers and designers. As a left-brained developer, you definitely do not want me involved in an application’s UI design. (Trust me on that!)  The good news is that in WPF, you don’t need to worry.  I can focus on the application’s functionality and the design work can be handled by a truly capable UX designer.

You may reasonably be wondering, "What does application development and design have to do with control development and design?"  Control development in WPF is very much just a microcosm of application development in WPF. I tend to write my application objects (user controls, windows, pages, the application itself) in the exact same manner as custom controls. This enables designers to create a UI that simply reflects the state of the application objects. If you think about it, this is a little M-V-VM pattern built right into WPF’s control and application models.

To fully appreciate the workflow that this model enables for both designers and developers, you just need to experience it once… You turn over a really drab, form-looking UI to your designer and watch what they do with it… Wow!  It’s an amazing feeling just to think that you had some part in the creation of such a thing of beauty! 

Perhaps you think this is just hyperbole.  Well, I know I’m not the only developer who feels this way!  And you, too, can feel this exuberance enabled by the developer/designer workflow.  Simply download Podder and toggle between Josh’s skin and Grant’s skin!  (Sorry Josh. :P)

Back to the issue at hand…  I happen to be very good at analyzing a control to determine the states that it will need to support. I’m also quite adept at implementing the functionality of a control and making sure that the functionality is exposed via the necessary methods and commands. Moreover, I’m very passionate about this type of control development.  I think the designers I work with will validate that I always strive to provide them with all the hooks they could possibly want when it comes to styling and templating my controls.

The term that WPF uses for this control model is "lookless". It basically means that the code for a control (or application) is written in a manner that makes no assumptions about the presentation layer. The control simply exposes state information via properties and events along with execution entry points via methods and commands.

Silverlight’s templating model completely breaks this lookless control model. It requires that the developer meddle in areas where they don’t belong (such as looking for and executing storyboards in the UI layer). Furthermore, it takes away the ability of designers to think outside the box when they define UX interactions because they must conform to whatever hooks have been provided by (a.k.a., hardcoded into) the control.  Or worse, it encourages designers to actually meddle in the control’s code where they don’t belong.

Without the lookless model, you cannot achieve what Nathan describes as the "holy grail" for developer/designer workflow. I completely agree. (Nathan’s blog, by the way, is another excellent resource for anyone who would like a designer’s view of the WPF and Silverlight platforms.)

The process of creating great controls will always involve designers and developers working together to meet each other’s needs. However, they each have their own strengths. As a developer, I DON’T WANT TO THINK ABOUT DESIGN!

The reason I am so passionate about the WPF platform is that it frees me to do what I do best… write code. At the same time, it frees designers to do what they do best… create compelling user experiences by designing the look and feel of an application and its controls. This is all enabled by WPF’s styling and templating model.

The arguments I keep hearing for the decisions being made with respect to Silverlight’s templating model all seem to revolve around toolability. Namely, applications like Blend need a more intuitive way to support styling and templating.

My stance is that the architecture of the platform should not be driven by the needs of the tools. The platform should definitely accomodate those needs, but this can be done through helper classes. The platform’s architecture needs to be driven by decisions that best enable the next generation of killer software experiences. I fully believe these experiences can best be enabled using a truly lookless model. I also fully believe that this model enables the most ideal workflow between developers and designers.

So how can Silverlight fix this?

Simple. Give us property triggers, data triggers, and event triggers in both styles and templates.

11 Responses to “The BIG Problem with Silverlight's Control Templating Model”

  1. Jeremiah Morrill says:

    BAP! Not sure if you’ve seen Barry Lyndon, but I think you should stick with it until you are given "satisfaction".

  2. Rob Eisenberg says:

    Preach it…

  3. Dr. WPF says:

    Thanks, Jer! You just reminded me… There’s a new episode of John Adams on tonight. Nice!

  4. Denis Vuyka says:

    I think we all will be happy enough if there won’t be any difference between Silverlight and WPF except renderers 🙂 So my voice is not only for triggers but for eliminating the phrase “subset of WPF” for Silverlight at all. Guess this is what Silverlight team is working on at least from public point of view.

  5. Chris says:

    I totally agree, we need triggers in Silverlight! In fact, I’m holding out until Beta 2 to do any development in Silverlight in the hope that they are added in. After using them alot in WPF, I don’t want to have to re-work some of that code to get it going in Silverlight.

  6. Josh Smith says:

    I have been yelling for triggers in SL2 for a while, too. But the problems around templating are an unacceptable ramification of not having triggers.

    BTW – your comments about my Podder skin bwoke my wittle heart! 🙂


  7. Marlon Grech says:

    I am with you here…. Silverlight needs (MUST) to have the same Model as WPF…. The way I see it, WPF is a tried and tested approach that WORKS! It makes the Developer + Designer workflow a beauty… Why are we going to change it in Silverlight and re invent something else… It does not make any sense…

  8. Joe says:

    After playing with the beta for a few weeks, developing a control in Silverlight is like walking through mud. I hope these following things get looked at: Inherited Styles, Property Triggers, Event Triggers(more than just Loaded), Routed Events, ICommand, Element binding. Coming from WPF I’m not sure why the change in the model? I’m still scratching my head over it. Silverlight is still lacking parity with its big brother, and its painful.

  9. Rob Burke says:

    YES! PLEASE! Cast my vote for property, data and event triggers.
    /me too

  10. Ryan Brown says:

    Agreed, Silverlight desperately needs feature parity with WPF on the important things.

    Keeping the size down is important, but not THAT important.

  11. Tom McKearney says:

    I absolutely agree with you on this. My colleagues who have only done Silverlight stuff don’t understand what the problem is. I went from WPF to Silverlight and it’s been agonizing!