I WPF, Therefore I Blend

If you’re a developer doing WPF development, you really need to be using Expression Blend.

Yes, I know the party line on WPF development runs something like this:

  • Every dev team should have at least 1 developer and 1 designer
  • Developers can’t design decent-looking GUIs to save their soul
  • Designers can’t be trusted with code, or anything close to code (excepting XAML)
  • Devs will open a project in Visual Studio and do all of their work there
  • Designers will open the same project in Blend and do all of their work there
  • Devs wear button-up shirts that don’t match their Dockers
  • Designers wear brand-name labels and artsy little berets

I don’t quite buy into the idea of a simple developer/designer separation, with one tool for each of them.  (I also don’t wear Dockers).

It’s absolutely true that Blend makes it easier for a designer to be part of the team and work directly on the product.  The old model was to have the designers do static mockups in Photoshop and then have your devs painstakingly reproduce the images, working in Visual Studio.  The old model sucks.

The new model, having Blend work directly with XAML and even open the same solution file as Visual Studio, is a huge advancement.  Designers get access to all of the flashy photoshoppy features in Blend, which means that they can do their magic and create something that actually looks great.  And devs will instantly get the new GUI layout when they use Visual Studio to open/run the project.

The problem that I have with the designer/developer divide is as follows.  To achieve an excellent user experience takes more than just independently creating form and function and then marrying the two together.  A designer might create GUI screens that are the most beautiful thing on the planet.  And the dev working with him might write the most efficient and elegant code-behind imaginable.  But this isn’t nearly enough to guarantee a great user experience.

User experience is all about user interaction.  Poorly done user interaction will lead to a failed or unused application far more quickly than either an ugly GUI or poorly performing code.

So what exactly is “user interaction”?  In my opinion, it’s everything in the application except for the code and the GUI.  User interaction is all about how the user uses your application to get her work done (or to create what she wants to create).  Does the application make sense to her?  Does using it feel natural?  Allow her to be efficient?  Are features discoverable?  Does the flow of the application match her existing workflow?

The only way to get user interaction correct is to know your user.  This means truly understanding the problem that your users are trying to solve, as well as what knowledge they have about the problem space.

There is an easy four step process to get at this information: 1) talk to the users; 2) prototype; 3) observe them using the prototype; 4) repeat.

There are a whole host of specific strategies to help you in this process, including things like: use cases, user stories, storyboarding, etc.  The literature is full of good processes and techniques for working early and often with users to get both the right set of functionality and a great user experience.

But let’s get back to designers and developers.  The reason that I don’t buy into the clean GUI/code split (or code + markup, if you’re a Petzold fan) is that good user interaction requires both code and markup.  Somebody needs to be responsible for the user interaction model and it should come first, requiring some code and some markup.

If you do buy into the devs-Studio/designers-Blend party line for WPF development, there are two simplistic approaches that you might be tempted to take, both equally bad:

  • Developer codes up all required functionality, puts API on it and designer creates screens that call into the API
  • Designer mocks up screens and then developers create code behind those screens to get desired functionality

The problem behind both approaches is, of course, that no one is focused on how the user is using the application.  The designer is thinking about the user in aesthetic terms and that’s a huge improvement over a battleship grey GUI.  But it’s not nearly enough–not if your goal is to achieve a great user experience.

If someone needs to be responsible for the user experience, it should be the developer.  If you are lucky enough to be working with a designer, the developer is still the team member that drives the entire process.  The designer is likely working in support of the developer, not the other way around.  (Note: I’m talking here about developing rich WPF client software, rather than web-based sites or applications.  With web-based projects, it’s likely the designer that is driving the project).

My vote is for a process that looks something like the following:

  • Developer initiates requirements gathering through user stories and use cases
  • Developer starts sketching up storyboards, with input from designer
  • Developer builds prototype, using both Visual Studio and Blend
  • Team presents prototype to user, walks through use cases, gets feedback, iterates
    • Important to focus here on how the user works w/application, rather than how it looks
  • As pieces of user interaction solidify
    • Designer begins refining those pieces of GUI for aesthetics, branding, etc.
    • Developer begins fleshing out code behind and full functionality
  • Continue iterating/reviewing with user

You might agree with this process, but say that the developer should work exclusively in Visual Studio to generate the prototypes.  Why is it important for them to use Blend for prototyping and iterating with the user?

The simple truth is that Blend is far superior to Visual Studio for doing basic GUI layout.  Using Visual Studio, you can definitely set property values using the property grid or by entering XAML directly.  But the property editors in Blend make it much easier to quickly set properties and tweak controls.

Given that the developer should be doing the GUI prototyping, I think it makes sense for them to use both Blend and Visual Studio, rather than just Visual Studio alone.

The bottom line is this: the choice of using Blend vs. Visual Studio should be based on the task that you are doing, rather than who is doing that task.  Instead of Blend just being a tool for designers and Visual Studio a tool for developers, it’s more true that Blend is a tool for doing GUI design and Visual Studio a tool for writing/debugging code.  Given that I think the developer should be the person responsible for early prototyping of the GUI, they should be using both Blend and Visual Studio during the early phases of a project.

So if you’re a developer just getting into WPF, don’t write off Blend as an artsy-fartsy tool for designers.  Instead, just think of it as a GUI design tool.  Though you may not be great at putting together beautiful user interfaces, it’s definitely your job to create the early GUI prototypes.  You may not be responsible for the design of the GUI, but you should be responsible for designing the GUI.  So if you WPF, you really ought to Blend.  Who knows?  You might like it so much that you start wearing a beret.

2 thoughts on “I WPF, Therefore I Blend

  1. So with WPF you have to double the cost it takes to create an application as compared to VB6, Windows Forms or whatever Java gui toolkit is popular these days?

    Not everything is a beauty contest.

    There is a huge difference between usability and making everything look like a video game. I think you can teach developers usability and can reasonably expect that they can design half-way decent data entry screens.

  2. Doubling the cost–you mean because of having a designer on the team? Or did you mean having to use two tools?

    Absolutely agree–not every team needs, or should have, a designer. In fact most won’t, especially if they are doing straight-up business apps. I think it IS important for devs to have expertise in designing user interaction, because you always need something that is usable. But I don’t think you need someone that has an eye for “pretty” GUIs.

    My point was–if you ARE on a team that has a designer, don’t just let the designer gen up screen in Blend and then throw them over the fence. As a dev, you should start initial user interaction design WITHOUT your designer, and using both Blend and VStudio.

    If you’re on a team without a designer, I think you should take the time to learn Blend–it’s not just about pretty, but also just a better XAML editor, plain and simple. That was sort of my epiphany with Blend–the perception is that it’s used only when you need to make stuff pretty. But as it turns out, it’s just much more productive for setting control properties than VStudio is, for WPF/Silverlight apps. I’d previously thought that you’d only go to Blend for doing “pretty” stuff like animations, but even just setting props on a Label, it just gives you more power. Seems sort of like having intellisense vs. not having it.

    I think longer term, VStudio should definitely get some more attention to make it more powerful as a XAML editor and let it “catch up” to Blend. But for the moment, it seems a bit shortchanged–so Blend is worth looking at to improve your productivity.

    As a separate issue, the pricing model should probably change. Blend should just “come in the box” with VStudio, rather than being a separate product that you pay for. But if you have an MSDN subscription, it’s a moot point, because even Blend 2 is now part of a regular MSDN subscription now, so it’s essentially free. (At least I got it w/my subscription, which I get through the Empower ISV program).

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Connecting to %s