Monday July 13, 2009

Silverlight & Blend 3 Sample Data

Well as of July 10 Silverlight 3 is out. Over the next several weeks I will be putting together blog entries on my favorite features of silverlight and blend which will enable us to make experiences faster and more engaging. I’m going to shoot for one a week, lets see how it goes.

Making design time data standard practice

One of the nice features added in Silverlight 3 and Blend 3 is that of sample data. The design ability of enumerated controls like itemcontrols and listboxes in the past using blend 1-2 has not been the greatest. Which was really a pain to deal with as so much of RIA is built out of these enumerated controls (after all a Listbox can be just about anything in WPF and Silverlight). More often than not designers would draw a listbox out as a series of objects in for example a stack panel. Usually because it was just too darn difficult for a designer to design a listbox with out design time data. For example take the following UI (now developed using blend sample data).



Ideally a designer would already have a MVVM framework set up for them and design time data ready for them. However often timing wise this would not be possible, so in its absence a designer would create XAML that looked something like this:



Instead of a a listbox with a data template the designer creates each element as copy of the items XAML. Instead of actual data bound to the text the values would be hard coded. This might also involve a Custom control being used in the data template. Either way the designer would be drawing the different enumerated states, then a developer acting in an integrator role would turn this scroll+stackpanel+grids into a proper listbox.



Which in the end could result in the broken egg scenario (see see tooling slides slide 33). As you will notice in the screenshots above the text doesn’t quite match nor do the paper lines. This is because as the developer takes this over as integrator, there was too much that needed to be changed and the design starts to sway from the original. In addition the developer would likely be developing custom code in the view model to display the test data in the designer and Blend.

All and all this together can be a total pain in the designer developer workflow.

How can it be done easier in Blend 3 / Silverlight 3

Enter new sample data in blend 3 and Silverlight 3. This feature is here to help bridge the divide between developers design time data strategies and Designers living in blend. Keeping as much design power as is possible in the hands of the designer themselves. At its core its very simple, the following screencast shows how to get it going:



Steps to adding sample data in blend

• Add a new sample data source in the data tab
• This will add a new sample data source to you app.xaml or document
• Edit the sample data to meet your needs
• The sample data will be stored in your application as a xaml file
• Set data context and your binding is ready to go

As you can see in this demo, a designer can easily use blend to create a basic model to bind to. With the data in place and no developer support a designer can then easily design the data template and all the data states of the listbox. In general this is very similar to the same concept in Flash Catalyst, make it easy for Designers to understand how ever very flexibly worked into the full workflow as just standard xaml and c# code.

The good and the bad

Overall I like this feature a lot, however there are some workflow and overall architecture issues to consider. So here’s your pros and Cons. I think overall the good > the not so good at this point.

The good

Enables designers using blend to design enumerated controls much easier than before

Enable designers and developers to work on separate schedules. This can be even more a benefit on prototypes and quick turn around projects

Enables developers to work on UI skinning etc, without having to wait for the model to be settled and or muck in code just to add sample data

Allows for conditional compilation to suppress design time data in production build

Can be used as simple data source for small prototypes as shown above

The not so good

• To support unit tests you may end up having to maintain several levels of test data to support developer (viewmodel unit test), designer (xaml design), server (wcf unit tests).
• As that designers / developers can be binding to sample data it can become easy to bind to a field in sample data that will never be in dev data, adding to the possibility of hard to track down binding bugs. For example designer binds to PageNumber but the field in the real model is PageNumbers, when the data context is switched to live data the binding will fail
• As that designers can easily build up a data model in blend, it may lead down to solutions which simply wont work with real development models.