It's been a lot of fun seeing the excitement building around Windows® Presentation Foundation (WPF) in its first months in the wild. The introduction of Expression Blend™ has solidified WPF as the first user experience platform from Microsoft built with designers in mind. This designer empowerment has been made possible by XAML, an XML-based model for describing objects. In the case of WPF, XAML describes controls, styles, and animations. Being XML-based enables XAML to be much more toolable than the C# or Visual Basic® code that is generated for Windows Forms applications, which means designers can focus on the appearance and interaction of an application instead of the programming details.

This XAML-based future is not without its detractors, though. I've chatted with more than one frustrated developer who laments, "I just want to write code." That reaction probably results from a combination of fear of the unknown and lack of knowledge. As someone who joined WPF halfway through development, I can attest to a bit of XAML skepticism. "What? Another way to instantiate objects?" Believe me, XAML is to be embraced, not feared. When you want to understand the layout of an application, it's a lot easier to understand a page of nested elements and attributes than a page of squiggly braces and semicolons. You also gain portability as XAML is designed to be usable across tools.

So where does the developer plug in? Are fans of Visual Basic and C# left to write event handlers for buttons? Not at all. At the Mix 2007 conference in Las Vegas, I outlined three roles that let developers deliver real, non-trivial benefits to WPF applications while providing a great "better-together" experience with XAML content. These roles feature the developer as plumber, as widget author, and as groundbreaker.

The developer as plumber is the idea that many developers are not interested in UIs and prefer instead to enable designers by building powerful data layers. Suppose you want to build an application to track a set of stocks. By defining each stock object with public properties, it's easy to define data templates to visualize each stock. If the objects implement INotifyPropertyChange, the visualization will transparently update as the data changes. You can leverage WPF command infrastructure, via the ICommand interface, to allow declarative access to business object behaviors. For instance, instead of just exposing a Refresh method, expose a RefreshCommand. This can be connected to a button or menu without writing event handlers. Commanding will even disable the associated UI when the action is not available, which gives someone using design tools the maximum flexibility in the creative process while isolating business logic.

A savvy designer working with Expression Blend and a well-defined data layer can go a long way. Most of the in-box controls can be tweaked with styles and controls templates. Binding and data templates enable rich visualization of business objects. In the end, though, a designer is limited to the controls and elements—the "widgets"—that WPF ships with. But developers can drastically improve the effectiveness of a XAML-defined application by defining new, custom widgets to target a given scenario. Imagine a design that calls for an arbitrary number of elements to be arranged in a circle. The naive way to approach this would be to build the elements using drawing APIs. Though this would be perfectly fine for a constrained scenario, it is limited. If the appearance of a child element needs to change, the code needs to change. A better approach would be to subclass Panel. Now you have an element that can be used on arbitrary visual elements, in a design tool, and with an ItemsControl to display arbitrary data items. This is just one example. There are many ways to address design challenges in WPF. By understanding how various components work together, a developer can design widgets with the maximum flexibility.

If "plumber" is coding to stay out of the way and "widget author" is coding to play well with others, "groundbreaker" is stealing the show. At its core, WPF has a powerful 2D/3D graphics engine. While important pieces of this engine have been exposed via controls and other framework features for XAML-based tools, much more capability lays waiting for a clever coder to unleash. Whether it's leveraging interoperability between 2D and 3D to build novel data visualizations or rolling custom animations to provide organic transitions, the developer—compiler in hand—has the most power and flexibility in the WPF world. Combined with a strong vision and a set of best practices, there is no limit to what designers and developers can accomplish in WPF.