Introduction
Producing great software involves a wide range of factors: visual appearance, interactions, appropriate content, responsiveness, and more. To optimally address this broad set of factors requires different skills: a graphic designer to create stunning visuals; an information architect to organize, prioritize, and interrelate the content; and a developer to integrate the visuals with the content and any back-end systems. For a single person to master all of these different skills is impractical or uncommon. As such, great software most often requires multiple roles to come together; at the highest level we often label these roles as developers (including architects, coders, testers, etc.) and designers (graphic, interactive, visual, etc.).

The premise of combining designers and developers to create a better experience is not new, but it has also never been an efficient collaboration. In Microsoft's new user interface platform Windows Presentation Foundation (WPF)1, an emphasis has been placed on the collaboration between these two roles, creating a revolutionary way to create software. Evidence of this claim can be found in both analyst reports2 and in solutions being brought to market3 today.

What has Microsoft done differently? 4 The convergence of this new platform and the new tools creates a collaboration workflow in the software creation process that ultimately leads to increased productivity, faster time to market, and higher fidelity in the design. This paper explores this assertion, with the aim of outlining both theoretical and tactical ways to realize the possibilities of "the new iteration."

This paper is the result of both research and firsthand experience by the authors. The research was conducted with a number of agencies currently working with WPF, and their insights are peppered throughout the paper. Additionally, the Expression product teams themselves were interviewed, not only because of their extensive knowledge of the platform and tools, but because the Expression products themselves were built using WPF.
How the Paper Is Organized
There is significant density to the paper, not all of which is relevant to every audience. The paper has multiple agendas and serves multiple purposes. The best way to navigate through the paper is to pick a path based on what you seek.

The section "The XAML Revolution" is geared toward those new to the platform who want to understand the underpinnings that make the new iteration possible. It is more technology focused and delves into the reasons that XAML enables a new kind of developer/designer collaboration.

The next two sections, focused on roles and tools, provide a bird's-eye view on the workflow as a whole and are perfect for people who are overseeing and coordinating a project. They are also appropriate for designers and developers themselves, because the sections talk about how their day-to-day job may change when using this new platform and tools.

The final two sections are oriented specifically toward designers and developers; they contain tactical tips and tricks for those venturing into the platform. These sections may be of less interest to audiences other than the rank-and-file members on the production line.
Note on Silverlight
Microsoft's Silverlight, a cross-platform plug-in for creating rich interactive Web experiences, also uses XAML. Many of the tools that are discussed in this paper generate XAML that can be used in a Silverlight application. Despite the significant overlap, this paper does not address Silverlight for several reasons. First, although Silverlight 1.0 has been officially released, many of the associated tools for creating Silverlight projects are still in alpha and beta states. Second, this paper focuses on creating rich interactive applications for the desktop; Web applications are different enough that they warrant separate treatment in a future paper.
The XAML Revolution
The key to realizing frictionless developer/designer collaboration in WPF applications is XAML. However, XAML alone does not engender this new collaboration; it is the underlying WPF platform, manifested through XAML, which allows for the efficiencies to be realized. As such, it is critically important to understand how XAML works, how WPF is manifested in XAML, and some of the architecture of the system as a whole. Unpacking the questions "Why use a markup language?" and "What differentiates XAML from other markup languages?" leads to interesting insights and deeper understanding of the possibilities inherent in the platform.
Why Use a Markup Language?
There are several markup languages for expressing user interfaces today: HTML, XUL, SVG, WordML, and more5. These languages, especially HTML, are the evidence of the success of using markup for displaying user interfaces. XML-based markup languages are well-suited to represent hierarchies and parent/child/sibling relationships that appear in a user interface.

A key to the success of markup syntax is the ability to be at once human readable and machine readable. This is an important point to call out because it speaks to the approachability of markup, especially compared to the learning curve that comes with procedural programming languages. There are many people with no experience writing software who are not intimidated by the syntax of HTML, for example. However, being able to understand the actual markup itself is an option and not a necessity. Tools are essential to generating markup syntax; in the case of HTML, the proliferation of HTML WYSIWYG editors has been key to its success.

XAML too is at once human readable and machine readable, allowing one to easily toggle between a tool and a text editor, a benefit that should not be underestimated.
What Differentiates XAML from Other Markup Languages?
XAML not only provides much of the functionality of existing markup languages but adds new features and capabilities not available in other technologies. XAML excels in three key areas: expressivity, comprehensiveness, and extensibility.
Expressivity
XAML's expressivity is broad and deep; it begins with all of the controls (buttons, list boxes, etc.), layout features (panels, grids, etc.) and text features (fonts, formatting, etc.) one might expect. You can see in a very compact example below the similarities between HTML and XAML, in which a page is displayed with a single button:

<html xmlns="http://www.w3.org/1999/xhtml" >
<body>
<input type="button" value="Click Me" />
</body>
</html>
<Page xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation">
<Button Width="100" Height="50" Content="Click Me" />
</Page>

A page with a button. HTML syntax on the top row, XAML syntax on the bottom.

XAML can represent more than controls, text and layout. It also has an entire syntax for representing lower-level vector graphics for describing shapes, paths, gradients, and more. The lower-level representations have a similar syntax to existing vector-based languages, providing easy migration from other vector-based languages.

<rect x="1" y="1" width="398" height="398" fill="none" />
<path d-"M 100 100 L 200 100 L 200 300 z" fill="#A3A993" stroke="A8806C" stroke-width="3" />
<Canvas xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" Width="398" Height="398">

<Path Data="M100, 100L200,100 200, 300z" Fill="#A3A993" Stroke="#A8806C" StrokeThickness="3" />
</Canvas>

Vector based representation of a triangle. SVG syntax on the left, XAML syntax on the right.

This expressivity goes beyond the representation of 2-D vector graphics to the arena of 3-D. XAML natively can represent 3-D scenes including cameras, lighting, matrix transforms, and meshes.
Comprehensiveness
XAML can represent far more than just visuals. It is here that XAML brings to life the underlying power of WPF. The most significant areas where XAML exposes power to enhance the designer/developer collaboration are styles, triggers, control templates, data templates, data binding, and animation. All of these features of XAML are unlocked by tools, such that the underlying implementation details of how the XAML works are hidden.
Extensibility
Technically, XAML is not a language itself but a .NET serialization and initialization language. Therefore, XAML can represent more than the features in the WPF platform; it can represent any custom controls, new animations, etc., as well as any .NET object graph. In a way, one might conceive of XAML as code represented as XML6.
Separation of Concerns Between the Designer and Developer
A byproduct of XAML's expressivity and comprehensiveness is true separation of user interface and business logic. Developers can work with XAML files created by designers with no loss of fidelity and no corruption of those artifacts; at the same time designers are given the power to create user interfaces, behaviors, animations, and even wire basic bindings between UI and data.
Roles and Workflow
With the introduction of XAML, walls that may have existed between designers and developers are no longer in place. The result is a new kind of collaboration. Consider the observations from a designer and a developer:

"XAML rocks because designers can work in tandem with developers. Most of the time I work with my own separate Blend projects, but there is also a constant weaving between myself and the developers. It's almost like we are playing tennis, volleying projects back and forth. With each exchange we both learn a little more about the tool and each others' perspectives. In result, this benefits the project and the end user." Kalani Kordus, Designer, Yahoo

"Because XAML dissolves the barrier between designers and developers we are no longer forced to work with a hard design freeze. Instead it's more a 'design slush'. This means as long as the basic visual language is there, the rest can remain fluid up until the last minute with little-to-no impact on the work I'm doing. We haven't been able to do this with other technologies because they simply can't support the rapid and concurrent iterations that are happening with both the presentation and the code." Lee Brenner, Developer, frog design

Ultimately, the new collaboration means that iteration of a project can now happen in a much more fluid way. There is no longer the "one-way street" where a change to a specification downstream means a radical reworking of the entire application. The result opens up new possibilities for collaboration between the designer and developer, where a kind of dialogue is possible with the potential to foster greater creativity.

To help address navigating these new waters, we'll look at the implications of XAML for designers and for developers7. Then, we'll look at the workflow between these roles.
Implications for the Designer
The biggest change for designers is that their creations will actually be part of the solution and that they can be much closer to the actual software experience. There is no translation process; there is no sitting over the shoulder of the developer explaining the vision and making sure she is re-creating it in the code. This can be incredibly empowering for the designer: The designer's work is now part of the workflow itself. And, as suggested earlier, if there needs to be a change down the line, the designer can be inserted into the process and makes changes without compromising the project as a whole.

In the new collaboration model, the designer's prototypes can be actual functional prototypes. Using new tools such as Expression Blend, a designer does not need a developer to help mock up a concept. All the various interactions possible are available to the designer to wire up, from button clicks to image loads to resize events. The result is that a relatively sophisticated prototype can be created without the need for a developer to be involved, thus improving productivity in the process.

Once created and approved, those prototypes can likely be used in the final product, instead of just being a byproduct of the design process that has no applicability to the final product. Robert Tuttle, from frog design, said, "Our prototypes in the initial stages of a project used to be between 100% and 50% throwaway. With WPF development, our prototypes are down to 20% throwaway."

One important thing to call out is that, with the designer intimately part of the software development itself, designers (may) need to be more conversant in the implications of their work from a software perspective. Consider the classic pillars of software development: performance, maintainability, versioning, quality control, stability, etc. A designer's work could affect any one of these topics, and thus the designer may need some education and training to understand the implications of their participation in the development. Because they are most likely using a tool to create the XAML, there is the possibility that they could create something with the tools that isn't optimal from a software engineering perspective. Thus, they need to understand the implications of the tool(s). Specific ways to prepare for this are part of the third section of the paper.

In the "old way," designers created mock-ups of the software, requiring developers to re-implement that vision, an inherently "lossy" process. In the "new way," XAML is the lingua franca between designers and developers.

Implications For the Developer
The perspective of the developer changes with the advent of XAML. Because XAML is so expressive and so easily generated with tools oriented to the designer, much of the user interface work that traditionally fell into the hands of the developer may now be in the hands of the designer. This can be incredibly liberating, freeing the developer to focus on other aspects of the engineering. However, as part of this bargain the developer may also end up giving up some ownership.

Another change brought by XAML for the developer is a need to structure projects that are conducive to optimizing the workflow. Tasks such as creating the initial project, setting up directory structures, resources, modules, and more become that much more critical for the developer to establish. Much of the success and efficiency that can be realized by XAML comes with up-front planning, most of which falls in the hands of the developer.

Implied in this assertion is the additional recommendation that developers need to understand XAML. In researching this paper, there was unanimous agreement that "XAML fluency" is a necessity for developers working on WPF. Ken Azuma, a Senior Experience Architect from 2nd Factory and author of a book on Expression Blend, noted, "As projects grow in complexity, there is a need for close attention to be paid to the XAML itself." While much of the XAML will likely be created with tools by a designer, the developer needs to understand the implications of what these tools have created. The developer may also be responsible for integrating and structuring the various assets created by the tools; thus, understanding XAML is imperative. The reality of WPF development is that XAML is more than just an implementation detail. Relying solely on the tools without understanding what they are creating can lead to a less than optimal outcome down the line.
Two (or More) Cooks in the Kitchen: Roles and Responsibilities
We have established that the premise of this new collaboration is getting the designer more involved in the creation process and bringing the designer's assets directly into the application. Consequently, establishing a process for exactly how these assets are incorporated is critical. Because each project varies with regard to team size, skills, and knowledge of the new technology, there is not a single recommended team model. That said, our experience with early-adopter projects shows two common approaches to managing the process. The first model, the designer/integrator/developer model, introduces a new role in the software creation process, that of the integrator, whose job is to integrate and optimize the visual design elements in the project. The second model, the designer/developer model, does not introduce a new role but rather assumes that with explicit boundaries and good communication the designers and developers can work in parallel and integrate visual design with functionality in the application. Each of these models comes with a set of advantages and disadvantages. In addition, each model has variations depending on the skills of the team.

While there is no single recommended team model because skills are different across teams, there is one single best practice that we have identified across all models: identify a clear owner for each task or deliverable. Let's elaborate these team models so the ownership recommendation can be explained.
Designer/Integrator/Developer Model
Some believe that XAML carves out a new role in the software development process, one that straddles the line between designer and developer. The most pragmatic title that's been proposed for this new role is the integrator, a term coined by IdentityMine, who has done a significant amount of thinking on the topic. Paul Alexander, a technical program manager with IdentityMine, has noted, "The Integrator understands the needs of the developer while also supporting the needs of the designer to assure that the app's UI is as compelling as it was designed, while also validating that the concepts can be realized in code from the developer."8

The ideal integrator is an individual with design sensibility and good knowledge/understanding of WPF and XAML. The integrator becomes the owner of the XAML and the interface between the developer and designer, making sure that the XAML file is always optimal. It is the integrator's role to structure the XAML and modularize the XAML where appropriate. As such, the integrator is a XAML expert and understands WPF concepts such as inheritance, styles, and resource look-up.

One of the advantages of having an integrator is that some of the onus of responsibility is lightened for the designer and the developer. With an integrator, the design team might not need to ramp-up on XAML to get their assets effectively integrated into the project. For designers who do not want to learn the new tools or don't have the time in an aggressive project, they would be able to create assets in their familiar tools (for example, Adobe Illustrator) and export as XAML; the integrator then does any modifications needed to integrate this XAML into the project. Likewise, for developers who do not want to be concerned with how XAML impacts their code, the integrator can act as a buffer. Especially for short-term or aggressive projects, an experienced integrator can very quickly incorporate all the right visuals into a project and help to educate the developers/designers along the way.

On the other hand, it should be observed that there are potential downsides to the integrator role. It can be argued that understanding of XAML should be shared across the team and not isolated to a single point of failure with the integrator. Also, it has been observed that on larger projects, the integrator can become a bottleneck to the process because of the inherent 'iterative' nature of design - one hardly ever creates an asset or comp and not 'polish' or revise it. The designer-to-integrator transfer can be a task that repeats very often and that creates unnecessary overhead for each hand-off. In addition, an integrator can inadvertently change the original designer's vision by making tweaks when integrating the XAML into the project. Finally, as a project scales, multiple integrators in a project are harder to manage because their work may overlap and ultimately burden the designers and developers.

Because every project and every team is different, it is hard to make a specific recommendation on whether an integrator is a key ingredient to success with the new workflows engendered by XAML, but we needed to highlight the role as a possibility for those starting a new project.
Designer/Developer Model

In the designer/developer model, there is no need for a new role, but rather a need for establishing processes to manage how graphic and interactive assets are incorporated into the project. There are two main approaches that developers and designers have used to optimize workflow: the harvest model and the collaborative model.
The Harvest Model
The first methodology is one in which the developer "harvests" assets from the designer. Thus, the onus on integrating the assets falls on the developer. In this scenario, while the designers are creating assets that will be used directly in the project, the designers are likely not checking in files to a source control repository. In addition, the designers may not be able to compile and run the complete application themselves; they could be working on smaller, isolated projects and then having a developer aggregate or transfer their assets into the actual project. Effectively, the harvest model establishes a distinct handoff between the designers and the developers.

Within this model, the depth of the designers' contributions depends on the fluency of the designers with the WPF tools. For example, the designer may be handing off exclusively graphic assets exported from a tool, or the designer may be creating actual WPF animations, styles, and templates that are then incorporated by the developer. So, within this workflow, it is possible for the designer to be quite well-versed in the capabilities of WPF but still be one step removed from the project.

The advantage of the "harvest" model is that designers are directly contributing to the project without the responsibility of understanding how these contributions impact the project. The disadvantage is that the designer is abstracted from the project such that iterations still require a handoff procedure.
The Collaboration Model
The other option is for the designer to directly work with the project itself. With this option, any changes the designer makes are immediately part of the project. As such, the designer is actually authoring the solution in tandem with the developers. The designer may be checking XAML files into a source code repository and likely will be able to compile and run the application. This streamlined approach allows for seamless iterations. For many projects -especially more ambitious ones - this is collaboration nirvana. In fact, it is the long-term goal or evolution of any model; as designers get more experience and confidence with the platform, they can be more directly involved in the project as a whole, ultimately serving to streamline the process.

Fundamentally, the difference between these two options is about the boundary between the designer and the developer. There is not a hard-and-fast rule about how to demarcate this boundary. In fact, increasingly, the line is getting blurred as the software industry is seeing more and more designers who can code and developers who can handle graphic and interaction design. Regardless of the skill sets, what's important is to be explicit about what the boundaries are between the different roles for a given project. Clear understanding about who "owns" the XAML is critical. Another critical aspect is a packaging/hand-off strategy for these assets, which is covered in the tips and tricks section.
The Tools
Though XAML can be edited with just a text editor, it is more productive to use RAD (rapid application development) tools to create the user interface. Because XAML is XML-based, there are many tools that can either edit or export XAML. We don't cover every tool on the market in this paper, but we focus on the most popular. We have grouped the tools into three distinct categories: (1) tools that target XAML, (2) tools that export XAML, and (3) WYSIWYG XAML editors.
Native XAML Tools
These tools expose a design surface that generates XAML. They are inherently "two-way" tools, as changes to the design make changes to the XAML and vice versa.
Expression Blend
Expression Blend is an interactive designer for XAML-based applications. Using Blend, one can access the full expressivity of XAML: layout, graphics, controls, templating and styling, animations, data binding, and basic 3-D. Blend, true to its name, is the place where designers, interactive designers, and developers all come together. Designers will spend a lot of time in Blend creating visuals, styling, creating templates, and creating animations, as well as many other tasks related to creating the look and feel of an application. Developers will also spend a lot of time in Blend doing UI work, but will likely combine it with Visual Studio's debugging and rich code editing.
Visual Studio 2008
Visual Studio 2008 has a visual editor for creating WPF applications9 featuring an excellent XAML text editor with IntelliSense, rich layout and document navigation capabilities, and a hosting/extensibility model for third-party controls. However, it does not have visual editors for styling, templating, and animation. Blend and Visual Studio use the same project system and both serialize to XAML. As such, it is seamless to go back and forth between the two tools.

Existing Tools That Export XAML
These tools and plug-ins export XAML but do not work with it natively. They do not work directly with XAML. They cannot import XAML, producing a one-way flow from the tool into the project10.
Microsoft Expression Design
Expression Design is a vector-based tool for creating graphic design elements. Design can export both XAML and raster-based images. In Expression Design, the designer is not limited to creating graphics than can be represented in XAML. The designer can create the visuals and simply rasterize elements that are not supported by XAML. There are a few features that cannot be exported as XAML and are not yet supported for rasterization. These include blend modes and text on a path.
Adobe Illustrator
Illustrator is a popular vector-based drawing tool in the industry; because many designers are familiar with the tool, it is common for them to create their UI in Illustrator and then export it as XAML. There are two ways to produce XAML from Illustrator:
  1. Use a plug-in to export XAML from Illustrator11.
  2. Use Expression Design to import AI files, which can then be exported to XAML.
Some visuals that can be created with Adobe Illustrator do not translate to XAML. In particular, beware of the use of any effects or filters in Adobe Illustrator.
3-D Tools That Export XAML
WPF supports 3-D, and Expression Blend has support for basic manipulation of a 3-D scene, but the Microsoft tools do not yet support creating 3-D models. However, there are several converters available for converting existing 3-D assets to XAML; they can be found here: http://blogs.msdn.com/mswanson/articles/WPFToolsAndControls.aspx. Also, Expression Blend can directly import .obj files.

Similar to Expression Design and Adobe Illustrator, these 3-D converters are one-way tools and have the same potential for loss of fidelity when rendered as XAML.
WYSIWYG XAML Editors
"What you see is what you get" (WYSIWYG) XAML editors play a key role in developing WPF applications. Some of the most popular are XAMLPad, XAMLCrunch, and Kaxaml12. These editors are free, small, utility applications that implement some version of a split view; in half the screen one can type XAML and the other half one can see the visual rendering of the XAML. Visual Studio 2008 and Blend 2 will implement this split view feature, so it is likely the use of these lightweight editors will decrease; but it is still useful to have a lightweight editor without the extra overhead.
Summary Chart
The chart below compares these different tools, excluding the WYSIWYG editors, to provide an overview of the different features available:

Expression Design Expression Blend Visual Studio 2008 Adobe Illustrator
Layout Static, absolute positioned Dynamic Dynamic Static, absolute positioned
Styliing No Visual Editor No No
Templating No Visual Editor No No
Resources As export option Visual Editor No No
Code Support No Basic editor Rich IntelliSense No
XAML Round-trips One-way Yes Yes One-way
XAML exporting Limits capabilities early to prevent lossiness Yes Yes Lossy. Tools have more features than WPF does.
Animation No Visual editor XAML editor only No
Best Practices for Designers
For designers, getting started with WPF is mischievously easy; the tools are similar to existing design tools, and it is quite easy to drag and drop some visual elements and produce a stunning user interface. However, if such an approach is employed, the result may be an application that does not perform optimally or is not optimized for maintainability. The following advice represents a few of the most common lessons learned from real-world projects.
Budget the Design
Print designers often make decisions when creating assets for reducing the cost of printing their assets. This might include color reduction, impact font selection, and image size and detail. Application designers should also consider how to minimize cost when designing a WPF application. Understanding the cost of all these visual elements in your design is critical to create a responsive application that does not consume too many resources (memory and CPU). The rendering cost should be balanced against the target audience and the hardware they will have to run the application. The following are some examples of areas where budgeting can make a difference: These three items represent known areas where a designer can create assets that impede the success of the application, but it is not an exhaustive list. The main takeaway is that the designer needs to be cognizant of how the design can affect the performance of the application. Avoiding performance problems early is much easier than trying to fix them down the line.
Strive for Reuse
Learning techniques for reusing XAML assets is important for the designer for several reasons: The best way to drive reuse is through resources. XAML supports resource dictionaries that act as property bags for any 'resource' you want to share across elements. Expression Blend and Visual Studio work with resource dictionaries natively; there are many opportunities to package elements as a resource. Also, Expression Design allows you to export items as resources - it is the 'document format' option in the export feature15.
Understand One-Way Tools
When using one-way tools and exporters such as Expression Design or Adobe Illustrator, care must be taken such that iteration can still occur and the benefits of the workflow are achieved. The recommended practice is to never make changes directly to any XAML assets after those assets have been exported by a tool. By insuring that the XAML stays intact, these XAML assets may be exported and integrated into the project again with a minimum of friction.

For example, consider the following scenario: A designer creates a button in a tool and exports the art as XAML. Then, a developer modifies the XAML that was exported, perhaps changing a name. It is then decided that the button's color needs changing. If the designer goes back to the one-way tool and makes the color change, the XAML that is exported does not have the name change made by the developer. The button may no longer work in the project and will require that the developer go back and tweak the XAML again. Thus, the optimization for iteration is compromised.

A solution to this problem is that one must take great care when integrating XAML that has been exported from a tool. There are several tricks to minimize the chances that the XAML will be corrupted when the asset needs to be re-exported:
Group Objects
Much of what is designed must be grouped as a logical entity or object; if this grouping occurs from the beginning, it will expedite the integration in the development process. Consider the round button template in the image shown below from Expression Design. It consists of two ellipses and some content inside it. If it is exported as an object and has been properly grouped, the whole button is a reusable entity. However, if the object has not been grouped, it will export as three separate parts. The grouped version is obviously easier to carry as a single entity later.

Both Expression Design and Expression Blend have features to help create groupings that can be reused as objects.
Understand the Platform
For designers want to be closer to the process, learning more about how WPF works is essential.
Resolution-Independent Logical Units
WPF is resolution independent, but it has logical units to give elements a size. Each logical unit in WPF is 1/96 of an inch. A rectangle defined as will be exactly 3 inches wide regardless of whether the system's resolution is 96 dpi, 144 dpi, or something else. When working inside Blend and Visual Studio 2008, any conversion between logical and physical units is not noticeable because every element is in same scale; however, when importing content (raster images in particular) you will notice some scaling done to best accommodate the resolution independence in WPF. The following are the types of interactions you will see.

In Expression Blend and Expression Design, if you import a raster image that was created at 72 pixels/inch and is 216 pixels wide, Blend will scale the image by 4/3 (or 96/72) times its size. The reason for this scaling is that the image was 3 inches wide (216/72), so Blend scales it so the size in WPF is still 3 inches. If the image had been created at 144 pixels/inch, Blend would scale the image by 2/3 (96/144).

Similar scaling occurs in Expression Design if you open an Adobe Illustrator file that had units in pixels; if the illustrator file was in points, it will not be scaled (because points are also resolution independent).
Dynamic Layout and the Content Model
There are three basic options for layout in a WPF application:
  1. Static layout, in which everything is absolutely positioned and does not resize.
  2. Dynamic layout, in which UI elements resize to take advantage of the available space
  3. A combination of these two layouts.
Most of the one-way tools that export XAML work in absolute positioned coordinates (aka static layout). To do dynamic layouts, a native XAML tool like Blend or Visual Studio 2008 is required.

When working with layout, it helps to understand the content model in WPF. Some WPF layout controls can have one (and only one) child; other controls allow for multiple children. Some of those that allow multiple children allow those children to overlap; some don't. These requirements can be cumbersome, but can be generalized for designers into this generic guidance: A way to get some of the features of dynamic layout from a layout that was created in absolute coordinates is to scale the UI. There are two techniques for doing this: (1) using the WPF Viewbox control or (2) applying a Scale transform to any UI element, which will scale all of the contents (or children) within it.
Templates and Styling
WPF provides separation of business logic (behavior) and look and feel of a control by providing a control template that defines the visual composition of a control.

For example, the default control template of a button is a ContentPresenter inside a ButtonChrome.

<ControlTemplate TargetType="{x:TypeButton}">
<Microsoft_Windows_Themes:ButtonChrome ...>
<ContentPresenter ... />
</Microsoft_Windows_Themes:ButtonChrome>
</ControlTemplate>

A button based on the standard Windows theme.

If we wanted the button to be round, we could replace the ButtonChrome with a Grid and a round ellipse for its background.

<ControlTemplate TargetType="{x:TypeButton}">
<Grid ... >
<Ellipse .../>
<ContentPresenter ../>
</Grid>
</ControlTemplate>

A custom button.

Using control templates a designer to create a button that looks like almost anything by replacing the button's internal visual elements. It is important to note that replacing the template does not replace the behavior; this button still responds to clicks and mouse hovers with no additional work.

Once the skeleton (or visual elements) of a control have been defined by the control template, WPF also provides rich styling support for customizing the look and feel. By using a style, we can create a reusable group of settings (or attributes) to attach to an existing UI element to customize its look and feel.

To address a frequently asked question, the difference between control templates and styles is that a template replaces the visual composition of an element, while a style simply sets existing attributes or properties of an element.

There are many more details about how styles and templates work together that are not covered here, but a designer and developer should study and understand these two concepts carefully. These are the pillars of the separation (UI from code) that helps make the new collaboration model workable; by taking advantage of control templates, data templates, styles, and resource dictionaries, it is possible for developers to focus on logic (behavior) and designers to focus on visuals (UI).
WPF Animation
In WPF, animations are time-based instead of frame-based. The advantages of time-based animation is a more consistent end-user experience; in time-based animation 1 second is a well-defined unit, while in frame-based animation 30 frames can be 1.5 seconds or 1 seconds, depending on the system running the animation. The disadvantages are slightly more complexity on creating or visualizing the animation and the state before and after the animation. Using Blend, you can create an animation and preview how it will run, but for relative animations that don't have a starting point, it is harder to visualize the start/end point; to get around this limitation you can just set the starting point (0:0:0) of the animation and watch it run; once the animation is designed, you can remove the starting point to make it relative.
Best Practices for Developers
The new developer/designer workflow is based on increased collaboration between the roles. If developers optimize their code and process, designers will experience fewer problems when using the tools.
Embrace Blend
A key to optimizing for the designer is embracing Blend. By using Blend and making sure that projects can be opened in Blend, designers can stay involved in the process. When projects can't be opened in Blend, designers are effectively shut out of the process because they can no longer get a design-time view of the project. For a change to be seen, the project has to be recompiled and then executed again. As Robby Ingebretsen from IdentityMine put it, "As soon as it isn't viewable in Blend, working on the project becomes a 'tweak-compile-run' cycle, instead of a 'nudge-nudge-nudge' cycle."

Along these lines, if a developer has the option to create something either in XAML or in code, XAML is usually the better choice if whatever is created (an animation, for example) will need to be polished or tweaked by the designer in Blend. The discipline of working in XAML is an added cost for the developer, but it ultimately reaps productivity rewards and well as creativity rewards. If it can be opened in a design tool, it has the opportunity to have another's hands on it. But if it is isolated in code, the designer is prevented from accessing it directly.

A great example of the usefulness of being able to open projects in Blend comes from the Blend team itself. Samuel Wan, a program manager with Expression Blend, noted, "We built both Blend and the skin for Design using Blend. The ability to get immediate visual feedback from the tool was invaluable. In the case of Design, we were able to overhaul the look and feel of an eight-year-old product in a matter of months."
Understand Blend Internals
There are some internals of Blend that the developer should understand. When you design a scene in Blend, it loads into memory everything that you reference in that scene (controls, vectors, bitmaps, videos, etc.) and executes their initialization code. This means that, if the initialization code throws an error, it will trip up the tool and prevent it from loading that control. In the worst case, the whole scene will not load in the design surface. A common example is as follows: a developer creates a user control to display something, for example, 'patient info.' In the initialization code for the control, the developer parses the data context to get the first and last name of the patient. If the control is loaded into Blend's design surface without a data context, then the parsing code fails and Blend then fails to load the user control.

To avoid this type of problem, the WPF tools provide design-time APIs in the Microsoft.Windows.Design namespace to check if you are running inside a designer. With these APIs, you can check for the design environment and execute different code to prevent your control from throwing an error.
Take a Data-First Approach
This is not an absolute best practice because all applications are different. However, a large number of applications display or capture information that is stored as data. XAML has some great features for working with data, such as data binding, data templates, and more. The only 'gotcha' here is that you must have the data defined when you start working with the tools -this way the tools can autogenerate code based on your data schema.

For example, Blend supports creating data templates through a simple drag-and-drop operation of dragging a data schema (a CLR object or an XML schema). If the data and schema is ready before the designer starts the layout of the user interface, this will save time for both the designer and the developer. This way, the designer is accomplishing more than layout of the user interface; the designer is binding the UI to the business object schema, saving the developer from having to do that later. Using the schema from the beginning also saves the designer the work of modifying the design later because of changes to the data model.
Adopt Consistent Naming, Structuring, and Documenting of XAML Files
Another key to managing XAML files is to choose a naming convention for the elements in the XAML file. As the complexity of the project grows, a consistent naming convention is essential, so that elements can be found and understood. Large XAML files can be difficult to navigate when looking at the raw XAML. A developer is going to need to wire up events based on the names generated by a designer. Having naming conventions eases this pain. This is an area that is familiar to developers but may be new to some designers. Designers working with XAML need to follow a naming convention for the purposes of maintainability down the line. Designers also need to realize that they cannot change the name of an element once it has been named, as that element might be referred to by that name in code.

A note about names: be aware that when you name an object (x:Name ="" or Name="") the XAML compiler generates a variable as a member of the code-behind class; for most scenarios this is very useful for the developer and usually low-cost at run time (a few bytes of memory and a couple instructions of initialization code); you just need to be aware of the extra reference to your object. If you were loading and unloading named objects at run time, you would need to set the variable created to null for the garbage collector to clean up the memory for this variable while the class is still in memory.

The actual size of the XAML file can get extremely large, causing readability and maintainability issues. This can become especially problematic in the event that a person needs to hand-tweak the XAML. Blend provides a handy feature called "View XAML" that allows you to jump into the XAML right from the representation of the visual tree.

This helps, but it doesn't entirely solve the XAML bloat problem, as sometimes it is more difficult to see the templates or resources that are part of a XAML file. Modularizing XAML files is key, especially for a large project. Essential to modularizing XAML files is understanding what the different parts of the XAML files actually do. Paul Stovell16 breaks this down nicely, classifying XAML files as either functional XAML or resource XAML. Functional XAML files include things with top-level elements like Window, Page or UserControl. Resource XAML files have two subcategories: generic resource XAML files, which contain resources that are used throughout the application such as Brush and Style resources, and specific resource XAML, which contain resources specific to a particular Window, Control, or Page, such as a 3-D geometry. Stovell has an example application with a proposed directory structure that is worth checking out.
Choose Code-behind
Though WPF allows you to insert code inline with the XAML, this is not a recommended practice. Avoid it at all costs; placing code inside a XAML file breaks the separation between code and XAML, leading to a maintenance nightmare. Another more subtle decision is whether to initialize event handlers in XAML or code. When all event handler initialization is in code, the project is cleaner and event handlers are not scattered across a XAML file. However, if all event handlers are in code, an interactive designer in Blend can't work as effectively with the project and the different states that the application might enter. By allowing event handlers in XAML, the project is more accessible from Blend, but then it has the maintenance problem of event handlers defined in multiple places.
Architect for the Platform
This paper would be a book if we went into further depth on templates, styles, resource dictionaries, commands, data binding, dependency properties, and triggers. All of these features are available in WPF and are supported via XAML - and therefore are designer-friendly and exposed via Blend. A good rule of thumb is "if you find yourself coding UI logic, you are likely not using enough of data binding, triggers, and templates." As mentioned earlier, XAML is an incredibly expressive, comprehensive, and extensible UI language; this should be empowering the designer to create user interface and interactivity of the application, leaving the developer with tasks like business logic, componetization, creating custom controls, and exposing the data models.
Use SNOOP to Tweak XAML at Run Time
One problem endemic to the use of tools for creating user interfaces is that not all "states" of the application can be rendered at design time. Often, the application can get into a state that can be seen only at run time. As such, the ability for the designer or developer to work with that part of the application is limited. Fortunately, there is a fantastic tool available called SNOOP17 that provides the ability to change the value of any UI property at run time.

Aaron Jasinski, a designer on the Expression team who worked on the user experience and styles for both Expression Blend and Expression Design, noted that this was an essential tool for tweaking the user interface in many cases. The designer would be able to see a live view of what the application would look like and make changes to the properties. Then, a developer could incorporate those changes into the code. While SNOOP certainly isn't as sophisticated as a complete design tool, it is a very handy mechanism to modify the user interface at run time.
Acknowledgements
This paper would not have been possible without the help of many people. Thanks to Tim Aidlin for doing the graphics, the numerous reviewers who gave invaluable feedback and the early adopter companies whose experience with the platform helped inform the paper.
Footnotes
  1. For an introduction to WPF, see http://msdn2.microsoft.com/en-us/library/aa970268.aspx.
  2. See the Burton Group's XAML: Declarative Programming Advances in .NET 3.0 (http://www.burtongroup.com/Research/PublicDocument.aspx?cid=885) and Forrester's Why Windows Presentation Foundation Will Dominate Thick Client Development (http://www.forrester.com/Research/Document/Excerpt/0,7211,38241,00.html)
  3. For a list of case studies about WPF and Expression solutions, see http://www.microsoft.com/casestudies and http://www.windowsclient.net.
  4. For more on Expression Studio, see http://www.microsoft.com/expression.
  5. For a great list of UI markup syntaxes, see http://en.wikipedia.org/wiki/User_interface_markup_language.
  6. For scenarios where object serialization and initialization is not sufficient, XAML supports "mark-up extensions" where you can create behaviors that are attached to objects that XAML serializes; this is how WPF accomplishes its rich data binding and resource look-ups.
  7. It is worth noting that, for both the designer and developer, there is an upfront cost of learning the tools and the platform. Without this investment, much of the efficiencies to be gained in the workflow will be lost.
  8. http://blog.identitymine.com/blogs/paul_alexander/archive/2007/07/10/doing-a-wpf-project-got-an-integrator-cool-do-you-know-what-to-do-with-him.aspx
  9. This designer is code-named "Cider." A release of this tool is available for Visual Studio 2005 with one caveat: it is unsupported and released only as a CTP (Community Technical Preview).
  10. Not covered are the various converters (HTML, Flash, etc.) available.
  11. There are currently two Illustrator plug-ins, which can be found here: http://blogs.msdn.com/mswanson/articles/WPFToolsAndControls.aspx
  12. XAMLPad can be found in the Windows SDK. XAMLCrunch can be found at http://windowsclient.net/downloads/folders/controlgallery/entry2314.aspx. KaXAML can be found at http://notstatic.com/archives/49.
  13. See http://msdn2.microsoft.com/en-us/library/system.windows.media.drawingimage.aspx.
  14. See http://blogs.msdn.com/wpfsdk/archive/2007/01/15/maximizing-wpf-3d-performance-on-tier-2-hardware.aspx for some great tips on using 3d in WPF.
  15. When choosing whether to export directly from Adobe Illustrator to XAML vs. importing those assets into Expression Design and then exporting to XAML, one factor in favor of Expression Design is its support for natively exporting resource dictionaries.
  16. http://www.paulstovell.net/blog/index.php/xaml-and-wpf-coding-guidelines/
  17. http://www.blois.us/Snoop/