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)

I've just got back from Microsoft's PDC 2008. Most of my time was spent preparing for the Tesco/Conchango Day 2 keynote demonstration that I have been working on for the last month or so. Conchango are a great company - really forward thinking in terms of their focus on User Experience, and a great understanding of how to realize business value for their clients. This was a very interesting opportunity to work outside our usual space in healthcare and pharma, albeit under a hectic schedule! No secrets of the sausage factory here, but it was also good to see this kind of event from backstage. I will say that the AV setup was astounding. I don't think I've ever seen so many blinking LEDs, outside of a TV studio.

The Tesco grocery system was a standard WPF application - we took the classic View, View Model approach, talking to a backend WCF service (not dissimilar to the approach outlined in our whitepaper last month). And because this was a real client app, we've also got a great offline story - caching in a local SQL database, and making use of peripherals attached to the system (e.g. the webcam). I think it showed how effectively you can aggregate other services (e.g. the calendaring, facebook messaging) into an application to deliver something that is more than the sum of the parts. Obviously, it isn't a finished product - exactly what services should be aggregated, and how they are surfaced is still be determined with customer testing, but I think it shows how far you can go with this kind of thing. We also had the challenge of the broad range of machines we were targetting - from Windows XP all the way through to Windows 7 (on which we ran the demo). Working out interactions that are good with touch, stylus AND mouse is surprisingly tricky, and a new skill we're going to have to learn as this kind of hardware becomes ubiquitous.

Even more interesting than the app itself (to me at least) was the development process. This was the first time I'd had the opportunity to pair with a designer (Xamlist? Blender?) during the sprint (in this case the very talented Felix Corke, Conchango's lead Blendmeister). I've always been an advocate of meshing development and design as closely as possible. Developers have a good understanding of the structural decomposition of the application, and the designer understands the best way to surface that structure, in terms of both static and dynamic interactions. However, if you just "throw the app over the wall" from one to the other, the structure can become blurred (interactive components are not drawings), or the interactions become clumsy (combobox is really a compromise, not a first-class design element). A shout out here to David and Rich, without whom it wouldn't have been possible to complete the development so effectively.

Anyway - the rest of PDC. Obviously, Microsoft's Windows Azure announcement is very significant for the industry as a whole. Developing from the kinds of cloud offerings currently provided by Amazon, we have a broadly horizontal platform and fabric that offers an almost impossibly simple provisioning and deployment model. If they have the business model and privacy/security SLAs to back it up, then it will offer compelling value - not necessarily to large enterprise customers who already have this kind of thing on- or near-premises, but to the vast majority of SMEs who represent millions of developers out there. It might even change some of the dynamics in the investment community. If you don't need billions of dollars of hardware investment to scale up, maybe entrepreneurs will retain a little more equity and control in their businesses? [But, "Azure" really shouldn't rhyme with "Badger"]

The Oslo family is also important - if more low-key (so low-key, it didn't even get a mention in a keynote; pace a sidebar in the Don'n'Chris show). I think everyone was a little surprised that there wasn't more meat on the bones at this stage. In a peculiar way I can feel the ghost of that vanished pillar of PDC 2003 - WinFS. Modelling our information in a way that can be queried and analyzed by tooling, and providing models of existing technologies (WF-XAML, WPF-XAML etc) is clearly a step forward in application design, but there's a lot still to be worked out, finished or polished (versioning being a key element). That's fair enough; as the team pointed out, these are very, very early bits.

Finally, Windows 7. Windows Vista R2, and all the better for that. I have no real criticisms of Windows 7. The new start bar is extremely productive, and - something close to my heart - the drive for proper support for High DPI (finally replacing a whole bunch of those applications and control panel applets that have steadfastly refused to behave at 120DPI+). They're also pushing a new High Color Model (wide gamut/high precision) that will benefit visualization apps in science and medicine.

And there will be another one next year - VS2010 and Windows 7 will likely have shipped by then; start speculating now on what that will all be about...

Gosh - what a lot of people have come to read this whitepaper on building a .NET 3.5 application. (The BradA effect, I reckon).

In his comments, Brad mentions that he doesn't agree with all the assertions made in the paper - I certainly wouldn't expect him to do so (my own views are constantly in flux as I learn more every day).

I'm posting this entry to encourage discussion and disagreement!

Hello, and welcome to our new blog; I hope you find that there is some information here that you find useful – or at least interesting!

First, an introduction. My name is Matthew Adams, and I am Managing Partner at Ythos Ltd. My principal interest is to envision, create and implement new, life-changing technology. Every day, I am inspired by the real power that software has to change the world for the better; and with that in mind, I’ve spent most of the last decade working on platforms and products in healthcare and life sciences.

You can find out more about what we do for the day job elsewhere on this site, but this is more of an informal corner where several of the partners, associate consultants and our guest experts will be talking about their insights, challenges and interests. This could be anything from a personal perspective on an industry trend to a clever technique for fixing a coffee machine when the pipes get clogged through overfilling.

While Ythos offers strategic business and technology consulting services, we have not lost sight of the practical, and our team maintains a high level of expertise with the current Microsoft technology stack.