WPF makes Designers and Developers friends again
I have been playing around with WPF for a while and have been blogging about some of the technical aspects on it. However today I will like to touch upon another important aspect of WPF and that is designer-developer connect.
Having worked on Windows Programming using C++, MFC etc for a decade and working with the various controls, it is a real pleasure to see the capabilities now available to WPF developers. It is true to a large extent that with WPF and XAML and the tools like Expression Blend, designers and developers can work lot more closely than ever before. The working closely is more towards the ability for designers to style the UI for the WPF application and the developers to write the code for it.
The WPF controls are called as look-less controls and the designer can do just about any type of styling on them. WPF does provide for a great design support for the controls and the look and feel of any control is only limited by your imagination. It can be argued that designers can take Expression Blend and sit on a beach, let their imaginations run wild and create an out of the world UI (whether anyone in this world will use it or not is a different question) and then come back and give the developers the XAML which they can then include in their VS solution and stitch the application logic to it and be good to go.
However, if only real life was this easy! Many a times the styles/templates defined by the designer are applicable at runtime since they may be set to apply on specific triggers like say mouse hover or button or item click etc. In such cases, for the designers to be able to succcessfully build the style and test it, they will need actual data to be able to run the application. Designers can temporarily use dummy data like embedded XmlDataProvider, but that means that during actual code build, developers will need to replace it with the real live data.
Another similar issue is with the designer being live. Not the designer as in person, he/she needs to be alive anyway, but the designer surface in Expression Blend or VS. What I mean to say is that the controls and data providers in the XAML are instantiated during design time also. This means their constructors are invoked and hence requires that the code behind work properly, else designer (person) will be stuck with errors that they may have no clue on how to resolve. See some of the typical design time issues here and here. One of the common ways to handle XAML load issues is to use the DesignerProperties.GetIsInDesignMode API and based on the return value, avoid doing some processing that may require the application to be in running state (if return value is true).
However I would say that these are probably still small issues when compared to the ability of styling the WPF applications. The UX development has come a long way with WPF, since the earlier thick client applications (and with Silverlight for the Web). The designers and developers, by working closely, can really work wonders.