Expression Blend™ 3 includes a terrific new prototyping tool, SketchFlow, which is designed to provide quick and simple UI mockups for evaluating different UI alternatives. This new tool skews the balance greatly in favor of the designer first approach.

Expression Blend 3 now includes IntelliSense, a major convenience and productivity booster when hand-editing XAML and .NET code.


Figure 1. The appearance of IntelliSense in Expression Blend is quite difference from its appearance in Visual Studio even though its functionality is comparable.

Expression Blend now also includes a built-in code editor (also with built-in Intellisense support) which permits simple editing of .NET code without the need to switch to Visual Studio.

Since the first article was written, the number of built-in controls now included in Silverlight and/or offered by the Silverlight Toolkit, has significantly increased -- and many of the controls previously included have appreciably matured. This permits designers working with Expression Blend to accomplish more without requiring as much custom coding assistance from developers. Moreover, Silverlight and WPF Behaviors -- pre-built custom actions like drag and drop -- are also now included in Expression Blend giving even more flexibility to designers.

Expression Blend 3 has upgraded both the appearance and functionality of the Visual State Manager.


Figure 2. The Visual State Manager in Expression Blend 3 has undergone an appearance makeover.

Also, the Visual State Manager has been ported to WPF and is available in the WPF Toolkit on CodePlex.com. The most recent release of the WPF Toolkit (June 2009) lists the VSM in the Stable Quality Band (roughly equivalent to Beta). At the present time, certain manual steps are required to use the VSM in a WPF project but at least it is now possible to do so.

As had been promised by Scott Guthrie, Expression Blend 3 is now integrated with Microsoft Team Foundation source control. (Recall that source control is very important to facilitate the concurrent efforts of multiple designers and developers -- particularly when under harsh time and deadline constraints.) Meanwhile, for those who prefer to use Subversion source control, there is an additional option for Mac-based designers to run Expression Blend and Microsoft Visual Studio® on their computers: VirtualBox, an open source virtualization product, originally from Sun Microsystems.

Every application which requires interaction from a user needs both designer skills to be applied to the appearance and usability of the user interface and developer skills to implement the required functionality of that interface. While it is a well known fact that many (if not most) developers are somewhat challenged in the areas of both graphic and user interface design, it's also equally true that, many designers are simply not trained and/or proficient in "coding". For years designers and developers have had to work together developing applications not completely understanding the challenges the other one faces in doing their job—exacerbated by personality and communication issues between these team members. It seems that designers and developers on software development teams have always operated with an unhealthy tension—never good for the final product.

Microsoft has long been aware of this situation and with the introduction of Windows® Presentation Foundation (WPF) has made a real effort to address the difficulties of designer—developer interaction. Prior to WPF (and still true in other programming languages such as Visual C++® and Java), the user interface in an application was created in code by the developer, albeit typically using GUI tools. The situation in the area of web development is somewhat different where the user interface has historically generally been created in HTML, often including the use of ASP.NET® or Flash controls. In many cases (more commonly in the Windows world than in the Web), the output of the designer took the form of one or more Photoshop or Illustrator files which expressed his or her vision. Working from these files, the developer would then create the UI in code.

The heart of the new Microsoft strategy is to use a declarative language called Extensible Application Markup Language or XAML (pronounced zam-mel) to build the user interface both for Windows applications (WPF) and for web applications (Microsoft® Silverlight™). XAML, as an XML derivative (and somewhat similar to HTML), is a much more comfortable structure for designers to work with. By using Microsoft's new Expression Blend—a graphically-based tool for constructing user interfaces—designers can create a user interface and then hand over the XAML—a textual representation of the graphical UI—to the developer to incorporate into the application. Because Expression Blend™ uses the identical project structure as Visual Studio® 2008, and because both applications are able to understand XAML, design work can be completed using Expression Blend and programming functionality can be easily added using Visual Studio. In essence, this coordination between the designer tool (Expression Blend) and the developer tool (Visual Studio) is intended to put both designers and developers on common ground, able to work cooperatively on the same project with the same language.

The purpose of this article is to evaluate how successful this structure is to facilitate efficient designer/developer collaboration, as well as to provide some useful tips for minimizing any remaining difficulties. There is an excellent introduction to different techniques for designer/developer collaboration in the Visual Studio help files.

Designer First vs. Developer First
When working in a WPF/XAML/Expression Blend/Visual Studio environment, a major consideration in determining which party should begin the project (designer or developer) is the degree to which the developer possesses design skills vs. the degree to which the designer is proficient in Expression Blend and is familiar with the basics of programming. The goal, of course, in deciding who should begin the project is to minimize wasted effort by avoiding any actions which are inconsistent with the responsibilities of their collaborator. For example, a designer with minimal Silverlight experience could understandably be perplexed in choosing between a StackPanel, a Grid or a Canvas as the appropriate container for some combination of controls. Similarly, a designer might select a TextBlock instead of a Label if he is unaware that only a Label supports the use of an access key to navigate to an associated TextBox. Conversely a developer might set various control properties via code (in the Load event handler, for example) instead of in the XAML. This might lead to confusing results if the designer later sets any of these same properties in XAML (whether directly, in styles or in animations).

Our principal recommendation is that whichever party has more experience with the above-mentioned technologies should begin the process. This will frequently lead to a Developer First approach principally because, at least as of now and probably for quite a while longer, many more developers will be experienced with Silverlight than designers.

Some situations would require a designer-first approach. For example, when mocking up a project which needs further approval before full commencement, or where it is necessary to create a presentation for buy-in from upper management or for outside investors.

It is interesting to note that in discussions with other designers and developers regarding the relative merits of the designer first approach vs. the developer first approach, we found very little agreement. Accordingly it is probably best to conclude that this decision should be made on a case by case basis, hopefully, after careful consideration of the relevant factors and potential pitfalls.

Walk a Mile in His Shoes
Regardless of which party begins, the more that each party is familiar with the responsibilities of his counterpart, the smoother this collaboration is likely to be. Both parties should be very proficient in using XAML and both should be able to at least minimally use both Expression Blend and Visual Studio. For example, a designer should be able to start and stop animations in code since it would be quite inefficient to have to ask for the developer's assistance for such a simple coding task. Moreover, while Expression Blend is capable of performing most tasks via its graphical UI, there are instances where it is simply easier to hand edit the underlying XAML (as, for example, in the case of certain complex layout repositioning tasks). At the moment, hand editing of XAML is easier to perform in Visual Studio because of IntelliSense® and code completion, features not present in Expression Blend.

In the largest projects, the need for an understanding of both design and development has occasionally led to the use of an integrator who, by definition, is someone who possess both design and development skills. While further exploration of the integrator role is beyond the scope of this article, there is an excellent discussion of this topic in the Januszewski-Rodriguez article.

The Visual State Manager
The June Preview of Expression Blend 2.5 included an exciting new feature to facilitate UI design called the Visual State Manager. This Blend component (figure 1) allows a designer to configure every state of a control (e.g. Checked, Unchecked, Focused, Unfocused, Normal, Mouseover, Pressed, etc.) as well as the transitions between states without requiring any C# or VB.NET code. This makes collaboration much easier by giving designers complete control over the appearance of any control in or between any of its states without the need for any code behind.

Figure 1. The State Explorer for Visual State Manager shown for a Silverlight Button (To view, select the button and choose Object / Edit Control Parts (Template) / Edit a Copy)

There are a number of great sources which explain the Visual State Manger in significant detail, including the Silverlight (Beta 2) help files, the excellent tutorial by Ian Griffiths and the MSDN Webcast by Jesse Liberty. You can even get a very good introduction to Visual State Manager in just under ten minutes in this Christian Schormann video.

Respecting the Division Between XAML and Code Behind
One major key to collaboration success is to ensure that designer changes are reflected only in XAML and developer changes (insofar as they relate to program functionality) are reflected only in the code behind file. While the Visual State Manager goes a long way toward achieving this goal, it applies only to the states of UI controls, and not to animations in general. Given the minimal support for triggers in the current version of Silverlight, it generally is necessary to start any animation by calling the StoryBoard Begin method from code as in the following sample.

 (In the XAML file -- eg. Page.xaml)
        <Storyboard x:Name="myStoryboard">
        	....
        </Storyboard>        
(In the code behind file -- e.g. Page.xaml.cs)        
        myStoryboard.Begin()

To the extent that a developer creates anything involving the UI, as in the Developer First scenario described above, the developer should take care that to the maximum extent possible, the UI is built using XAML instead of code.

The most effective technique to achieve a rigid separation of XAML and code behind is through the creation—and rigorous enforcement—of a clearly defined policy. (And while we are on the topic of policies, it is impossible to overstate the importance of a well thought out, consistent naming policy.) As the animation trigger example illustrates, in Silverlight's current incarnation, this goal cannot be 100% achieved, although with proper effort, it is possible to come reasonably close.

Using Source Control
Source control has long been used to coordinate development projects with multiple developers to prevent two people from editing the same file at the same time as well as to ensure that only the most up-to-date version of a file gets used. This technique is equally valid for coordinating any project using both designers and developers.

Microsoft's latest source control offering is contained in Team Foundation Server which offers a modern, full featured version control system. Another popular open source option is Subversion. It is a viable alternative in that it works on the file-system level and the client is a stand-alone application that doesn't require the use of Visual Studio, project files, and the like. While Subversion has the advantage of cross-platform support, as a practical matter any Mac-based designer will have to use either Parallels or Boot Camp in order to run Expression Blend and Visual Studio.

Although the June Preview of Expression Blend 2.5 does not yet directly support source control, Scott Guthrie has indicated that this will be included in some future release. In the meantime, a designer can use Visual Studio to check out the files which he needs to work with if using Team Foundation Server. Subversion, by contrast, uses a command line client which checks out and re-submits files independently of Blend or Visual Studio. Our discussions with other designer/developer teams confirm the importance of using source control.

Designer Developer Communications
In this respect, a pre-commencement meeting between the designer and developer to discuss the specifics of responsibilities can be very helpful. Each party can enumerate areas of conflict or problems in earlier projects and suggestions on how to avoid them. Particularly if the plan is to use a developer-first approach, the designer could create a rough sketch or in some other simplified fashion describe his vision of the UI as a rough input to the developer. Since everyone's strengths and weaknesses vary, each party can identify areas which he would prefer the other party to avoid or conversely areas in which he would welcome the assistance of the other party.

After the project begins, the extensive use of comments in both the XAML and the code can facilitate designer / developer communications. One way to facilitate this is to have the designers and developers work on the same time schedule—or at least be contactable so that any issues which arise can promptly be resolved. To the extent that this is not possible, carefully constructed comments can represent a useful substitute.

An even better strategy would be to include the designer(s) in the daily or other periodic development team meetings. As previously indicated, the new technology (XAML) and the integrated tools (Blend and Visual Studio) permit the designer to become an integral part of the development team. While obviously this is easier if the designers and developers both work for the same firm and are not geographically separated, where this is not the case, improved conferencing technology can contribute to a greater degree of integration.

Conclusion
By comparison to the old methodology where designers created their vision of the UI using Photoshop or some other static view, Silverlight's XAML-based approach using Expression Blend and Visual Studio represents an enormous improvement. Moreover, Silverlight's highly flexible UI model makes it possible to build almost any design which even the most talented designer can imagine.

By following some of the guidance principles set forth above, it should be possible for designers and developers to work together in a highly efficient fashion, resulting in both a better final result and a faster time to completion than previously was possible.

Other Useful Links

* This article was commissioned by and prepared for Microsoft Corporation. This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY.