Developers, Designers, and WPF

As I mentioned yesterday, I heard at ReMIX from two teams of developers and designers who had completed WPF (Windows Presentation Foundation) projects using the Microsoft Visual Studio developer tools and Expression designer tools. The good news is that it can be made to work better than it used to, since Visual Studio and Expression integrate with common XAML; the bad news is that it still isn’t completely smooth.

How do you make it work? First, everybody has to be working from the same design documents and use cases and in general have some common understanding of what it is you’re trying to accomplish. I know, that sounds like Motherhood and Apple Pie, but all too often it’s a major stumbling block.

Second, you need a centralized repository that everyone can access. That can be a problem for designers, who often aren’t familiar with the need to check artifacts in and out. It can also be a problem for the tools: for example, the September Preview of Expression Blend 2 still isn’t able to check files in and out of Microsoft TFS (Team Foundation Server). In addition, TFS doesn’t do a very good job of merging XML documents, and XAML is just a dialect of XML. (You don’t have to use TFS, of course, but both of these groups did.)

Third, while developers can work entirely in Visual Studio, designers cannot work entirely in Expression Studio: they also need to use Visual Studio, at least a few times a day. Unfortunately, Visual Studio tends to put designers off: they have a hard time getting used to the whole idea of projects, much less getting the idea of needing to rebuild projects after the developers have changed some infrastructure that doesn’t seem like it should matter, or the idea of refreshing projects from the repository.

Fourth, both developers and designers need to understand what they can and can’t change about each other’s XAML. Developers have to learn to stay away from blocks of XAML that reflect carefully tuned designs; designers have to learn not to touch the names of XAML objects, since the names are what tie the XAML to the scripting. It turns out that it’s often OK to change the types of objects: as long as the original object type (a StackFrame, perhaps) and the new object type (a Canvas, perhaps) share all the events and methods being used by the application, you’re golden.

Both the Magenic CV application and the Infragistics Tangerine application show that you can build creative applications with WPF, of the sort that previously might have been built in Adobe Flash or Flex. This of course will trigger my distinguished colleague Tom Yager, who thinks that nobody in his or her right mind would give up Flash.

What I heard from these people, however, was that there are difficult cultural problems that often can’t be overcome in a Microsoft development shop that also employs designers who use Flash. They can be overcome with these tools: designers can learn Expression since it’s so much like the Adobe tools they know, and then they can become an integral part of the development cycle instead of a forethought or an afterthought.

Tony Handley described the alternatives quite graphically. If the designers come in at the beginning and give their concepts to the developers as drawings, the developers throw up their hands, say it can’t be done, and do whatever they can, and the result comes out looking nothing like the original concept. If the designers come in at the end to gussy up a working application, they basically have the job of putting lipstick on a pig. With the cooperative process that is possible with WPF and XAML, they can, with some care, iterate back and forth in a way that isn’t too frustrating for either the designers or the developers, and wind up with a working product that also satisfies visually.