Expression Blend – a powerful tool for developers

I’ve been experimenting with the use of Expression Blend as a tool in the life-cycle for day-to-day development for a typical .NET developer that might be writing an application using Silverlight with some sort of implementation of MVVM.

Having used Visual Studio 2010 as my primary, all-in-one tool for developing applications, I was somewhat sceptical of using Blend. When I had tried the earlier versions of Blend, I didn’t like the look of some XAML it generated. Moreover, I simply couldn’t see the point of it – why run two applications to do something when one can do it. I’m no UX designer – I’m a .NET developer! So why should I use some code-gen tool to write badly-formed XAML when I can hand-craft it and do a much better job of it?

However, I recently became more and more frustrated with the performance and reliability (or lackof) within VS2010 when it comes to authoring XAML-based UIs, and so a couple of weeks ago I decided to try Blend again, and I think that this time I’ve “got it”. I’ve been using Blend along with Visual Studio 2010 to develop a relatively small Silverlight application, and have found it to be a powerful and useful tool in the arsenal of an application developer.

Why Blend?

Whilst the VS2010 XAML editor isn’t that bad, there are a number of benefits that I’ve found in using Blend to VS2010: –

  • Because the Blend designer is much more powerful than VS2010, I can see how styles and data templates will look without having to run the application. You’d be amazed how much time this saves.
  • The Blend editor is much, MUCH quicker and more responsive than VS2010. It got so bad with me in VS2010 that I ended up writing all my views in XAML-only mode at one stage. With Blend, 90% of what I do is in the UI mode; occasionally I’ll switch to XAML or split view to fine tune something, but the tool is generally fine for every day UI design.
  • Animations and Visual States are much easier to design in Blend.
  • The XAML editor is much quicker in Blend, because it doesn’t have as powerful XAML intellisense as VS2010. This is actually not usually much of a problem because, as I said, you end up using the designer most of the time.
  • Much, much easier to design data templates (or create new ones based on an existing one)
  • Encourages you to write clear separation between your View and ViewModels – design the former in Blend, the latter in VS.
  • Easier to use behaviours – Blend has a built in repository of them so you can just drag them on. No faffing around with manually entering the namespace in your XAML etc.
  • Data Binding is quicker and easier to achieve – including use of converters etc..

    I’ll stop there, suffice it to say that for most day-to-day tasks, it’s a much more pleasurable experience (or less painful perhaps?) in Blend. There are a few things that I’m still struggling with, such as how to effectively generate fake data to test out my views, and also how to get better control of how your view model is created – I like using Unity to create my View Models (typically as a dependency setter on the View’s code-behind) but if you create your View Model in Blend as a static resource, you can’t really do this.

    Typical Workflow

    I have to say that I’ve been really pleased with using Blend, so much so that it’s now become my default environment for XAML authoring. The best part of it is how seamlessly it integrates with standard VS2010 workflow, which now goes something like this: –

  • Load the solution in VS 2010 on one monitor
  • Load the same solution in Blend on another monitor
  • Code my data models, services, and view models in VS 2010 with CodeRush etc. etc..
  • Build the project in VS
  • Switch to Blend. It automatically picks up any changes to the View Model.
  • Author the View in Blend
  • Save the View xaml file (not build – just save it)
  • Compile the solution in VS2010 (which picks up the amended .xaml file automatically)
  • Run
    It doesn’t sound much but I’ve found it to actually be a really compelling way to work.


    I still use VS2010 – it’s still a powerful development environment where I can quickly knock up code-based elements of my solution (especially with good old CodeRush) – but for designing views, Blend now has my full support. We’re often no longer writing simple WinForms that perform simple data binding with a couple of buttons and a listview. We’re now writing applications that have custom chromes, complex data binding with converters, asynchronous service calls with busy indicators, data templating etc. etc. – perhaps this is as good a time as any to treat VS as a code-first tool, and leave the UI design to Blend.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s