Whenever we run a WPF or Silverlight training event or lab, the one question that is guaranteed to come up relates to the designer / developer workflow on a project team.
In the old days of Win32 or Windows Forms, the workflow was straightforward (albeit extremely limiting). A lot of desktop application development teams I’ve seen, particularly in the enterprise, don’t even include a formal role for a user interface designer. Although the development team might include a business analyst or someone in a interface development role who would be doing some basic interaction design and application flow work, the actual interface would be mostly designed and implemented by the same programmer who was writing the underlying logic. On the other hand, for the projects where design was taken more seriously as a core element to the success of the application, the design and development teams were separated into different silos. The design team would often present their output in the form of a color printout of a screen designed with Photoshop in complete isolation from the actual tools or platform available, and the developer would then have to jump through hoops to painstakingly reproduce the design with tools that were never built for that purpose. The end-result was typically a disappointing compromise between the ideal that the designer had envisioned and what was practical with limited and stretched development resources.
WPF and Silverlight revolutionize that process by bringing the designer into the heart of the process. XAML becomes the shared substrate that can be used by both designers and developers to communicate their intent. Finally, the designer is not divorced from the development process: using a tool like Expression Blend to produce XAML, their artistry is no longer the inspiration for the final interface design, it is the final design. For the developer, they no longer have to waste time recreating controls that already exist in the toolbox simply because the designer has implemented a different visual representation; they can concentrate on the engineering challenges that will create the rich engine that powers the interface.
Such a transformation isn’t without challenges, however: it requires new forms of collaboration, different project team structures, and an updated cookbook of best practices. We’re keen to help you retool your workforce to take advantage of WPF and Silverlight, of course, and so Jaime Rodriguez and Karsten Januszewski have spent the last couple of months distilling their own experiences and interviewing early adopters into a new whitepaper that addresses many of these issues and opportunities in great depth. This is the first of a series of content on this and related topics; we hope to produce several more in the run-up to MIX08.
Read the whitepaper online or download a copy for offline reading or printing. What best practices would you suggest to a software house or enterprise embarking on a new WPF project? What else should we be covering with this series of whitepapers? Let us know what you think.