Having just completed a project pairing with a designer, I thought I'd post some of my observations on the developer/designer workflow in WPF. Following a long tradition, it's a top 10 list.
(Breaking with tradition, I'm counting up...but hey...)
1) Build a view model
The view model is the point of communication between you and the designer about what your application actually does (from the user's perspective). You should both have an intimate understanding of those data structures, what they mean, and, more importantly, how they change.
2) Learn to read XAML together
Until the angle brackets make sense to you both, it will be very difficult to work together. Note that I'm not suggesting that you necessarily both need to be able to write XAML, but XAML is the shared expression of how your application appears to the user.
3) Developer: open your work in Blend
Your designer pal will almost certainly be using Blend. You need to make sure that the XAML structure, Controls, UserControls etc. that you create all open correctly in Blend. Unfortunately, this means that there will be some restrictions on what you can do with external resource dictionaries, and you need to preserve the mysterious Blend namespace extensions and attributes.
4) Think about the Events and context/state changes in the system
As a designer, you will want to perform all sorts of interesting transitions and animations in the system. The easiest way for designers to Trigger those transitions in Blend is via a RoutedEvent on some UI component (or the new Visual State Manager support, where you are talking about internal control state). Although a suitable DataTrigger from the view model can often do the trick, this is slightly harder to deal with in the design-time environment.
The other way the developer can make life easier for the designer is to break a state change into two halves. Before you actually change state, raise some StateChanging event. Only commit the change when they set some other piece of data, or call a method (possibly off a Storyboard.Completed event). This allows them to transition existing visuals away, update the data, and bring in new visuals.
5) Build a library of value converters
You can work much more effectively with your designer if you've got a standard set of value converters that you both know how to use. Good ones to get started include
StringFormat
(if you are not using 3.5SP1)
Proportional
(scaled by some absolute range to vary between 0.0-1.0)
Divided
(divided by a constant factor)
Scaled
(multiplied by a constant factor)
BooleanToVisibility
(with properties mapping True and False to specific Visibility values),
OneMinus
(1 - x) and
Debug
(a pass through that allows you to set a breakpoint)
This is only really effective in conjunction with 6...
6) Learn to write binding expressions together
Although there is quite sophisticated data binding support in Blend (also coming soon in Cider), it will be much easier for you both if you learn to write binding expressions together in XAML. There are two aspects to this. First, it is empowering for the designer to be able to make sophisticated dependencies on the view model (and even the view), without requiring input from the developer. Second, it really helps if the developer understands what makes a view model easy to bind to. Binding syntax is gibberish to most developers, let alone designers - so, establish good examples and common patterns that you can use repeatedly.
7) Build UI at a component level
Identify early the UI components you want to build, and assemble them into the application. Just "drawing" the app (as is often the case with website design) leads to over-complicated, difficult to maintain XAML - and you often suffer from poor perf as a result. It also makes it cheaper to iterate the design (see 9). This can mean a completely separate step migrating visuals from a scamp in, say, Adobe Illustrator, to a build in Blend.
8) Learn the layout primitives together
The Blend design experience gives you a strong sense of an artboard or canvas on which items can be freely positioned, even though its basic layout primitive is actually the Grid. Get to a shared understanding of how the Grid works (a well understood concept to the designer, but perhaps not normally associated with the specific restrictions of the WPF implementation), and how you can break out of its clipping boundaries by use of the Canvas.
9) Learn how to iterate
It is much more productive to iterate with the designer. The developer is responsible for what the application does for the user, and the designer for how the user interacts with the application. Every time you transition from developer to designer, intents are blurred and structure created by one party is bent to the will of the other. Unless you make incremental steps on both sides, tidying everything up as you go, it can quickly become unmanageable for one or both parties.
One common problem is a view model that gradually becomes less and less suited to the interactions. A proliferation of value converters and requests for new events are symptoms of this issue.
Another is the "big ball o' angle-brackets" in the XAML file - a file comes back from the designer that is stuffed with paths, triggers and other gumph that make the structure impossible to see.
Sort these issues out early (e.g. by breaking XAML out into (user) controls or resources and identifying simpler primitives that can be used for the complex paths).
10) Acknowledge that the developer often has the easier job
For the vast majority of applications (in the UI tier at least) the developer actually has the easiest time of it. Most UI application structures are pretty simple, and building the view model, value converters etc. is not hard.
Designing high-quality visuals and user interactions is, on the other hand, extremely difficult. (If it was easy, then all our apps would look great and be a dream to use, and, frankly, they're not.) The developer/designer partnership works best if the UI developer, at least for part of the time, sees themselves as an enabler of the design vision for the application, and supports the designer in realizing that vision. In particular, you’ll find yourself having to build the complex and abstract animations that the designer will be describing to you. Conversely, the designer needs to be prepared to step up and take the lead when necessary, and see themselves as neither simply an artist, nor a "visuals factory", nor just creating a "skin" for some existing functionality.
The overall User Experience is a combination of good quality business analysis and customer representation, design vision (and innovation), and effective implementation. What I’ve outlined above really just talks to effective implementation. All three need attention, and a dash of design genius is necessary, but not sufficient. I'd like to sign off with the idea that great user experience is ultimately born of the single-minded determination to straighten out all of the kinks that appear when you give the product to a real user. When you get it right, this whole process is way more fun than we should be having, plus we’re developing business value for our clients!
You can find the value converters here:
Ythos.ValueConverters.zip (12.54 KB)