Expression Blend: Challenges and Opportunities

Update: Some designers have challenged me and said how can Blend be a production tool and not a conceptual tool too. My response to this is they're right and perhaps I should have chosen my works more carefully.

What follows is a clarification.

Expression Blend was designed first and foremost to be a tool that can be used in the production workflow of WPF and (eventually) WPF/e applications. It wasn't designed to be a competitor to tools that are engineered and dedicated to rapid software prototyping. But it's probably a bit broad to say that you can't use a tool like Expression Blend for conceptual design. What I should have said is that some scenarios where you are doing conceptual prototyping might require the creation of the application logic that will drive that prototype (there are of course many ways to create prototypes that have no need for application logic too). In those scenarios that application logic would be created in a tool like Visual Studio for WPF and your editor of choice of it was JavaScript for WPF/e.

Because of the fundamental separation of user interface and application logic that is inherent in WPF Expression Blend was always designed with the intent that it would be used in conjunction with other tools to create that application logic with Blend focused on creating a declarative toolset to create the interfaces, layout, interactivity and animation and provide the binding controls to the application logic.

What is the intent of Expression Blend

Regular readers of this blog probably know that Expression Blend is a product Microsoft has been developing and which will be shipping in the first half of 07. What may not be obvious to folks (and perhaps we could have done a better job of communicating this more explicitly) is what exactly Blend was created to do as a 1.0 product. This post is an attempt to provide some clarity to that and also hopefully spark some questions, these words are not all my own and they come from conversations I've have with designers that use Blend both within and outside of Microsoft and with people within Microsoft that work on the product teams.

Let's start with a debunking of the most provocative statement I hear about Blend which is this, "Expression Blend is a Flash Killer."

Nothing could be further from truth. Expression Blend is a production tool that is designed for building WPF and (eventually) WPF/e applications that is targeted at professional designers. It's primary intent is NOT as a conceptual interaction design tool ala Azure or iRise. Conceptual design is incredibly important and I think Blend will eventually evolve into a tool that makes it easier for newcomers to accomplish this but from a design goal perspective it was never an ambition to position Expression Blend as a tool that would replace or compete with Azure or iRise. Now I can say with conviction that folks that have been steeped in the world of .NET and C# and WPF are using Blend to facilitate interactions just like that but the reality is that it's pretty difficult for a newcomer come to Blend it make it work that way if you're not working with a paired team of designers and programmers (that understand C# or Visual Basic)  or happen to be one of those folks that does both. There are simply some types of interaction that are difficult to create solely in Blend right now as a 1.0 tool. But as you'll see by exploring some of the links I provide below there are also some fantastic capabilities in the tool for implementing a detailed design very effectively.

Will it get easier to do conceptual design in Expression Blend as we move forward? Yes. Do we get this is a real want and need of designers. Yes. The bottom line is that creating a click-through prototype in Blend today is tough, in fact it's probably the wrong tool for that today if you're trying to do everything yourself and you're new to the tool.

But if we shift the conversation a bit to talk about production quality interaction things start to look a bit different. Blend is designed to work in conjunction with Visual Studio, it was never designed to be a stand alone product (or rather, about three years ago, we decided that would be a tough direction to take things with the complexity of WPF and our desire to keep application logic separate from the presentation layer both programmatically and from a application/design/workflow perspective.

If you're talking about prototypes that are build together with a cross-disciplinary team of designers and developers the editing and debugging features in Visual Studio are necessary and handled well in Visual Studio. Are you a jack of all trades in the world of Windows software development? Then you'll probably find yourself using both tools but it's a different approach than folks coming from the world of Flash are used to.

I'd go so far as to argue that it is quite functional once your target is making a product together with developers rather than making a prototype as a designer on your own and if you're coming from the world of Windows the uptake is perhaps quicker for folks. We lament this or simply accept that that is where we are with Blend these days. Is it a material defect that means you should avoid the tool for production use. No. All the things we're doing today to rapidly and iteratively create prototypes aren't suddenly broken because Blend can't do this. Plus, those doing paired programming scenarios with teams of designers and developers can actually built great prototypes that can be moved right into production.

It's also important to remember that again, WPF and Blend are 1.0 products, this represents our first entry into the market, not a finalized vision for the future. Over the next few weeks and into the summer you are going to see Microsoft articulate this vision more distinctly for the standards based Web, cross-platform rich experiences and Windows application development. Blend lowers the impedence mismatch between the detailed design and production by using the same runtime for design and by leveraging parts of the interaction (via triggers, commands and databinding) within Blend in a declarative fashion. Nobody is claiming that this encompasses ALL of what designers do but it's a big step forward for folks that do application development today.

 

So now some hypothetical questions. Here we go...

Why does this feel so hard?

This feels hard because we've been talking too much about Blend and not enough about what is most important, WPF. WPF is a rich, complex, robust API built from the ground up to offer a dramatic new way to approach design for interaction designers. Blend is a tool for you to manipulate it. Much like a program like Dreamweaver or Expression Web lets you manipulate HTML or Maya lets you manipulate and/or create 3D models and animation.

You can learn how to play around with Blend in a few days. WPF can take much longer, weeks (months in the case of a dense designer like myself). But that investment pays off in a big way once you've made it because it lets you some working with the design directly through XAML and cleaning applying the application logic through C#, Visual Basic or in the case of WPF/e Javascript. So right now Blend is much more of a tool along the lines of an editor that expects you to understand what you're editing. Over time I think it will move away from that a bit to a tool that can let folks be a little more exploratory without the steep learning curve but it's probably always going to be in the realm of Web editor more that the realm of a tool that hides everything from you.

 

So, why is it worth it for me to take this pain and learn this?

This is a personal choice that many designers need to make. WPF Blend are NEW tools designers can use to add value to the software designer and development process. An investment in the platform can open up new revenue opportunities for the designers and alter the current iron triangle of what's possible in a given amount of time. Firms that have worked with WPF and tools like Blend are productive. Quality code gets created faster, people get to go home earlier, customers get delighted quicker and things cost less to care and feed for once they are deployed--and can me more easily and iteratively improved over time.  These are pragmatic but real things that we think WPF can enable for folks. There are some designers that won't play in this space and that's okay, there are others that will embrace it and continue to use the tools and platforms that they still love too.

 

So, coming from a different world what's different about Blend?

If you're coming from the world of Flash you'll find no equivalent to ActionScript 'in' Blend. It's not what the tool is designed for. You'll interact with Visual Studio and use C# and Visual Basic for the creation but not the linking to application logic if you're not taking advantage of or don't have a prebuilt library that will accommodate some of this for you. We try to keep you in a declarative world in blend with some rich databinding capabilities and through the use of these libraries. So if you're an ActionScript guy (I'm not) go pick up a book on C# (I think you'll be surprised and pleased with how easy and powerful it is) In fact, you'll probably have an easier time than I am as someone that came from comping everything in Photoshop and Visio.

Remember what Blend is, a production tool for creating user interfaces for Windows. This feels weird perhaps having two tools but Visual Studio is an IDE that is optimized for this. Will that change over time? I guess my question is should it? You tell me. For the record, Expression Blend includes a copy of Visual Studio with it for just these types of situations.

We also haven't talked about XAML. Blend does wonderful things to create XAML but go into code view and trying to tweak say...a gradient brush, requires that you understand what XAML is doing. That requires a learning curve, but you can trust that Blend will create XAML that works right for WPF without having to get bogged down in that if you want for WPF and (eventually) for WPF/e too.

 

Summary points

It's obvious by now perhaps but let me say it again. If you're not building a WPF application Blend is simply not for you.

It's a version 1.0 tool, things will change but its not our ambition that there's going to be a one to one correlation between everything Adobe does with their tools and what we do with ours. The market and the community will decide who is successful and there's plenty of room for both companies to be fantastically successful.

It's more about WPF than Expression Blend. This is different from a tool like Flash that doesn't care what you know about the SWF binary format or the Quicktime format to use FinalCut. An investment here is like the one made in HTML and CSS except for a platform that was designed from the ground up to support great UI.

 

Some Thanks to...

David Malouf for being a pioneer with our technology and having a dialog with us about it.

To Don Burnett for doing the same thing.

To Jon Harris, Leon Brown, Christian Schormann, John Gossman and Arturo Toledo in Microsoft for helping me clarify some of my thoughts and parse some of their own.