De WPF Integratio (About WPF Integration)

Introduction

I've been posting a lot about Silverlight lately, but hey, here is a WPF post, and about WPF integration, no less.
Note: To fully understand this article, you should have a basic understanding of WPF, styles and templates, triggers, etc...

In my current project at work, I act as WPF Integrator. I am that dude who sits between the designers and the developers, and tries to avoid that they fight too much. Or something. Sometimes it works, sometimes it doesn't, you know how it is with kids. They need their freedom. But I digress.

One important task of a WPF Integrator is (drum roll) WPF integration. For us, this operation usually occurs when we have a design iteration. The way we create application components is (roughly) the following:

  • The Developer creates the component in Visual Studio. The component is composed of a main assembly (EXE or DLL), containing "functional XAML" and source code (code-behind), and a "Skins" DLL containing XAML resource dictionaries.
    (Note: Because we don't want any source code into the "Skins" DLL, and to avoid circular references, we actually have a 3rd assembly called "Converters". As the name shows, this assembly contains the converters (and other helper classes) that are referenced from the Skins DLL).
  • Together with the WPF Integrator, they create a "raw" UI. That means a basic layout made of "functional XAML", according to the wireframes created by our user experience engineers.
    (Note: "functional XAML" is the XAML code that is not strictly doing look&feel. For example, a Button tag is functional XAML, while the style and template it uses are "design XAML").
  • The WPF Integrator prepares the Skins DLL by exporting all styles to it (using Blend). We follow certain guidelines in naming all the components (styles, templates, DLL names, etc...) and also in the structure of the styles and templates (see below).
  • The Developers start what they do best, Developing. Meanwhile, the Designer do what they do best (let me hear you:) Designing! This is the Design iteration I was referring to before.
    (Note: The Developer *only* works in the main assembly. The Designer *only* works in the Skins assembly.
  • If the Designer needs to change something in the main assembly, they contact the WPF Integrator to coordinate.
  • Similarly, if the Developer needs to change something in the Skins DLL, they contact the WPF Integrator to coordinate.
  • When a set of features are complete, the Developers' and Designers' work is integrated and tested.

Typically, we integrate the design to the application during design workshops, where a couple of Designers and Developers (and the WPF Integrator) sit together and work together, pretty much in an Extreme Programming spirit. These workshops are very intense and interesting, and usually allow fast progress in the application's look&feel.

Conventions, file structure, naming
  • A control refers to a Style which in turn refers to a Template (this is to facilitate the designers' job in Blend).
  • A control does *not* set its template directly, but always through a style.
  • If triggers are needed in the main assembly, the local style refers to a "BasedOn" style located in the Skins DLL.
  • A Style key is named like the control it refers to, suffixed with "Style". For example "MySpecificButtonStyle" or "ListBoxStyle" (for all ListBoxes), etc...
  • A Template key is named like the control it refers to, suffixed with "Template". For example "MySpecificButtonTemplate" or "ListBoxTemplate" (for all ListBoxes), etc...
    (note: We use the "Template" suffix for ControlTemplate and DataTemplate).
  • The skin resources for a given control are stored in a resource dictionary file with the "Skin" suffix. For example, the control "MyUserControl"'s resource dictionary is named "MyUserControlSkin.xaml".

These guidelines help the designers to understand which Style and Template belong to which control. Note that Blend makes that task easier by allowing to navigate from the main assembly to the Skins assembly with a succession of clicks.

Typical Designer workflow

The very first task a designer must do when he gets the code is to understand its structure. This is where the conventions mentioned above help. Typically, they work this way:
(Note: You can download a sample application here, open the SLN file in Blend, and then open the main window (Window1.xaml))

  • Open the application's main window in Blend and check the logical tree.
  • If a user control is found, right-click on it and choose "Edit control" (fig 1). This opens the User Control XAML file in Blend.
    (Of course, this fails if the User Control's source code is not available).
  • For any control they want to skin, select the control, and then choose the menu "Object / Style" (fig 2 and 3).
  • At this point, the style chosen can be local (for example if the Developer need to use a Trigger, etc. See listing 1). The Designers are trained to check the name of the file in which they are currently located (in Blend). If the file is named without a "Skin" suffix (for example MyPlugIn.xaml), they may not edit it. In that case, they look for a BasedOn style (fig 4). If they are currently located in a file with a "Skin" suffic (for example "MyPlugInSkin.xaml", then they may edit it (fig 5).
  • Once in the Style, they can select the context menu "Edit Control Parts (Template) / Edit Template". This opens the Control Template in Blend, where they can rework to look&feel of the control completely (including triggers, animations, etc...)
Figure 1: Edit control
Figure 1: Edit control
Figure 2: Selecting a control
Figure 2: Selecting a control
Figure 3: Edit style
Figure 3: Edit style
<Button Content="GO" Grid.Column="1" Click="GoButton_Click"> <Button.Style> <Style TargetType="Button" BasedOn="{StaticResource RoundButtonStyle}"> <Setter Property="IsEnabled" Value="True" /> <Style.Triggers> <DataTrigger Binding="{Binding ElementName=DirectoryNameTextBox, Path=Text}" Value="{x:Static sys:String.Empty}"> <Setter Property="IsEnabled" Value="False" /> </DataTrigger> </Style.Triggers> </Style> </Button.Style> </Button>
Listing 1: Local style using a Trigger, Based On a skin style
Figure 4: Edit
Figure 4: Edit "based-on" style
Figure 5: Editing the style in the Skin file
Figure 5: Editing the style in the Skin file

Note: Here we see the advantage of setting the "Template" property in the Style instead of directly in the control: The Designer can see the "shape" of the control already in Blend, without having to rebuild.

Figure 6: Editing the template in the Skin file
Figure 6: Editing the template in the Skin file
The importance of Blend

This workflow would fail miserably without Blend. It can never be repeated often enough: You should keep your application Blendable! (as long as possible). Blend will fail to represent the UI in some circumstances. For example, if your application connects to a COM based component, this is something that Blend cannot handle. Similarly, if your application uses any kind of network service to get data, Blend won't be able to represent this data. This is where the MVVM (Model - View - ViewModel pattern comes handy: By enforcing a data-driven UI, you give the developer the possibility to create "design-time" data, i.e. data which is only used when the application runs in Blend (or in the Visual Studio WPF designer). I could talk about that for hours, and this jumps the scope of this post, but you can read more info about MVVM here:

Using WinMerge as an integration tool

During these integration phases, I use WinMerge a lot. The reasons for using this merging tool are multiple:

  • It is probably the best merging tool currently available for Windows (if someone disagrees, don't hesitate to comment below!!).
  • Our Designers don't work in our source control infrastructure. They get a copy of the code, refactored as a standalone application. This allows them to test the application easily without having to install a whole networking system (our application is following a Service Oriented Architecture). The aplication they get features a test mode, allowing them to simulate certain conditions (again, see my TechDays talk and the source code for details). Because they work disconnected from the source control, a merging operation is needed.
  • The merging steps give me a good occasion to review the Designers and Developers work, and to understand it. This is an additional step towards code consistency and code quality (4 eyes review principle).

WinMerge is simply amazing, a must-use tool for a WPF Integrator (at least if you work according to a similar workflow as we do). It is free (amazing, when you see the quality of this tool), was clearly developed by people who needed such a tool and decided to create it (according to the "eat your dog food" idea), and can even be integrated into your favourite source control framework (yes, even ClearCase, which we are forced to use). You can compare folders, binary files, text files with a very clear user interface. All merging operations can be performed using the keyboard only, which is extremely ergonomic. Honestly, I love that tool.

By the way, I didn't mention it yet, but you can also edit both files you are comparing in WinMerge, and save both of them.

WinMerge, merging tool
WinMerge, merging tool
Conclusion

Much has been written about the Designer-Developer workflow, the WPF Integrator role, the MVVM (or MV*) pattern, etc... In our project, we have the chance to use these principles in a real life situation. I can honestly say, I rarely had so much fun developing software ever. The only thing I can think of that made (almost) as much fun was the big ASP.NET project I worked on prior to this one. The Integrator role is a great place to be.

(Note: I also file this under Silverlight because WinMerge is also very useful for Silverlight integration, even though the Style and Template system is not as rich as in WPF yet).

Print | posted on Friday, April 11, 2008 10:38 PM

Feedback

# re: De WPF Integratio (About WPF Integration)

left by Dr. WPF at 4/12/2008 12:40 AM Gravatar
Excellent article on the integrator role, Laurent! Thanks for sharing your story!

Clearly, you have a much more structured approach than most shops and it appears to be working out well for you (assuming that your enjoyment level is an indication of success).

Glad to hear it! I love to hear WPF success stories, especially around developer/designer workflow. I know there are a lot of skeptics out there regarding this "new iteration".

I approach WPF from the dev side and I totally agree that this is the best platform *hands down* when it comes to enabling designer/developer collaboration. I also agree that the integrator role is critical to making that collaboration work (even for smaller shops where a dev or designer may have to assume both his traditional role and the integrator role).

I hope that your designers and devs share in your feelings of job satisfaction. If so, then you truly are a success story! :-D

Cheers!
-dw

# re: De WPF Integratio (About WPF Integration)

left by jay at 4/12/2008 1:31 AM Gravatar
It is probably the best merging tool currently available for Windows (if someone disagrees, don't hesitate to comment below!!).

.. Have you tried Beyond Compare? I think it does a smarter job.
www.scootersoftware.com

# re: De WPF Integratio (About WPF Integration)

left by Laurent at 4/12/2008 8:30 AM Gravatar
Doc: To be honest, this is a good weather scenario that I describe here. In any big project, you will encounter variations to this "perfect workflow", and some variations require a lot of patience to solve. Do I sound arrogant if I write that it also needs talent? It can be tricky sometimes.

That said, the biggest challenge I have to face every day is not technical, but rather the fact that, from a management point of view, the importance of design is not totally understood yet. We still have a lot of educative work to do...

Jay: No I didn't try BeyondCompare, but I sure will! Thanks for your comment!

# re: De WPF Integratio (About WPF Integration)

left by David at 4/13/2008 4:01 AM Gravatar
How much of this would apply to SilverLight?
(Forgive a newbie for asking...)
Thanks
David

# re: De WPF Integratio (About WPF Integration)

left by Matt @ Xceed.com at 4/14/2008 2:39 PM Gravatar
Great article, it's also basically what I do at Xceed when it comes to skinning our dataGrid or working on samples for our product. We have a designer that makes most of the design in fireworks and or illustrator (sometimes in blend but without any functional triggers, just to give me an idea of the layout). I try to avoid using Blend as much as I can. I do most of the integration directly in VS2008... I think Microsoft is on the right track with Blend but it still needs a few updates. Here's one of the first project I've worked on if you guys are curious : http://download3.xceedsoft.com/demo/gridwpf/Xceed.Wpf.DataGrid.Samples.LiveExplorer.xbap

# re: De WPF Integratio (About WPF Integration)

left by Laurent at 4/14/2008 2:54 PM Gravatar
I got a message from Josh Smith regarding the article (I had sent an email to Josh about it). For some reason, Josh was not able to post on here, but he sent me a message to Facebook and allowed me to copy it here.

"This post is very informative and interesting. I really appreciate the details you provided regarding how each participant is "scoped" in what they can do according to his/her role"

# re: De WPF Integratio (About WPF Integration)

left by Laurent at 4/14/2008 3:06 PM Gravatar
@Matt: Interesting comment! If you have specific issues with Blend, let me know, I am working quite closely with the Blend team at MSFT and passing them feedback. They are very attentive to what the community does with the tool. On my hand I try to do as much as I can with Blend, and it works not too bad, but in fact I always have VS2008 in the background to "fine tune" things.

# re: De WPF Integratio (About WPF Integration)

left by WPF developer at 4/24/2009 7:03 PM Gravatar
Really great article, I was searching for ideas about WPF integration and found it, so thank you.
But sill I have some questions, don't u think that Blend is too much complex for designers? and the second what about Expression Design, when doesn't inter in action?

# re: De WPF Integratio (About WPF Integration)

left by Brent Schooley at 11/13/2009 6:18 AM Gravatar
Laurent,

I just wanted to let you know that this article and Nate Dunlap's "So ya wanna be an 'Integrator', huh?" are the two articles I go to when I need to train someone new on what an integrator does. Thanks for summarizing things so well.

-Brent

# re: De WPF Integratio (About WPF Integration)

left by Laurent at 11/13/2009 7:19 AM Gravatar
@Brent, really happy to read that, even more since Nate is actually my boss at IdentityMine :)

@WPF Developer: I don't think Blend is too complex for designers, but the fact is that many designers use tools that they know, and are a bit reluctant to change. This is why we found out an additional role to be most efficient. As for Expression Design, I saw designers use it and it works fine. We really have a wide choice when it comes to design and integration into WPF/SL, which is great.
Comments have been closed on this topic.