XAML – the future of the designer developer workflow

Since the day I got started playing with web technologies back in 96, (I was early but not there right at the start as I was still too busy doing print design) the same question has always been asked… but never satisfactorily answered.

How do designers and developers work together. 

This has never been resolved and today there is still a lot of friction between designers and developers. Why is this such a difficult problem to solve? Designers have great tools to build the graphics and interactions of the application (both desktop and web), developers have great tools to build the underlying architecture and business logic but gluing these things together has always been so difficult.

Maybe the issue is that simple, the term gluing. Designing and developing shouldn’t be glued together, they should be treated more like ingredients that get mixed together in the right quantity. Sometimes a little more design, sometimes a little less.

In the projects I’ve observed and worked on with designers and developers, they have generally worked as separate teams, not side by side, and I mean literally side by side in the same room. Over the course of a project no real understanding of each others art has been built up. And up to now it probably wouldn’t have made any difference anyway because the workflow would still have been broken.

Designers get frustrated when developers fail to understand the importance of why a button needs to be 3 pixels further to left, or why the shade of blue that looks the same but isn’t, really matters that much. Conversely the designer doesn’t understand that it might take a lot of effort on the developers part to actually recode the application to move that button 3 pixels to the left.

This is a difficult cycle to break because developers don’t speak JPG or GIF and designers don’t speak code (or at least they shouldn’t have to). So you are left literally gluing the different pieces together.

What XAML does is it allows us to break down the barriers in this designer developer workflow. It enables designers to use the same common language as developers and visa versa. This is a key change, and has probably been easier for Microsoft to address as we’re entering an established market (visual design) but without the baggage of multiple versions of previous products. This has allowed us to actually address and solve the real issues rather than just putting sticking plaster over them and hoping it all hangs together.

So what is XAML – a short definition from : http://www.xaml.net/

“XAML is a declarative XML-based language that defines objects and their properties in XML. XAML syntax focuses upon defining the UI (user interface) for the Windows Presentation Foundation (WPF) and is therefore separate from the application code behind it.”

Great… but what does that really mean in terms of workflow?

What it actually means is designers and developers can now speak the same language, XAML, for both Windows desktop applications through WPF and the web through WPFe).

Expression Design enables designers to build the UI elements of their applications and export them as XAML.

Expression Blend allows you to take those graphics and add an interaction model and build out the presentation layer of the application. The native format of Expression Blend… is XAML.

If a developer is working in Visual Studio to build the underlying architecture of the application the language used to describe the presentation layer is XAML… designers and developers can for the first time work seamlessly together.

In fact Expression Blend and Visual Studio even share the same project files.

If a designer has been working on an application and the developer needs to do some additional work to the architecture this can be achieved without disturbing the presentation layer. And the reverse is true to, designers can work on the presentation layer without disturbing the underlying application architecture.

Separation, yet integration of presentation and logic. The holy grail… and it works.

Already XAML exporters have started to appear in early form for many different products, Illustrator (http://www.mikeswanson.com/XAMLExport/) and Fireworks (http://www.infragistics.com/design/#FireworkstoXAMLExporter), Maya (http://www.highend3d.com/maya/downloads/tools/3d_converters/3782.html) as well as complete applications such as XAM3D (http://www.erain.com/products/ZAM3D/DefaultPDC.asp).

XAML is a great step forward, but it’s only as good as the tools around it. Luckily for me tools like Expression Blend already go far beyond what any version 1 tool should be capable of. Seeing peoples eyes light up as you edit a button, or a data bound list box by simply right clicking and then visually editing the components template complete with live data… is just superb fun… excuse me sir would you mind picking your chin up off the floor… 🙂

I’ll talk/ramble more indepth about XAML. But for now… must dash… I’m off to the Vista launch geek dinner… and running late… eek… very late!!


0 Responses to “XAML – the future of the designer developer workflow”

  1. Leave a Comment

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

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

Google+ photo

You are commenting using your Google+ 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

%d bloggers like this: