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.