One of the questions I've heard a number of times is, "I really want to use WPF, how can I convince my boss?"  I've generally shied away from answering, since there's a lot of factors specific to your situation that I don't know.  What kind of business are you in?  What's your boss like?  What's the relationship between you and your boss?  Etc.  But it comes up enough that I think it's time I took a first draft at this, and with your help and feedback we can refine this into an answer you can use.

I guess if I only got three sentences to convince a generic boss, it would be "User experience is a driver of software sales & productivity.  And WPF lets you build that better user experience.  So start planning for WPF now -- even if you can't start using WPF tomorrow, have a plan in place for how & when you will take advantage of WPF."  Of course, I'd customize that for any particular boss.  Two of the more important angles are, is your boss a business person or a technology person (or some mix thereof), and is your company selling software or writing software for internal use.  The facts and main selling points stay the same, but I'd spend more time on different points for different audiences.  But let's continue with the "generic boss" theme so we can make progress.

User experience matters.  Nobody builds character mode DOS applications anymore, not because those applications have fewer features than their GUI counterparts, but because the GUI apps have a better user experience.  And Win32 vs. WPF is a similar jump.  Sure, WPF apps can look better and have a certain sex appeal.  But it's not just eye candy -- WPF gives you the power to visualize data in new ways.  That's going to be very specific to your application -- it might be visualizing the flow of electricity through a power grid, or charting a patient's medical history, or the flow of materials through your manufacturing process, or arranging photos into the most compelling slideshow.  But that visualization is real, and it makes your users more happy and more productive.  Here, a demo is worth a thousand words, and a demo of your business is worth ten of somebody else's.

Another thing to keep in mind about user experience is that standards are rising.  Just think about Web pages today and ten years ago.  For consumer-facing software, the days of any UI being good enough, no matter how ugly, are behind us, and standards are only rising. Business software is a little less sensitive to good-looking UI, but even there, standards are rising -- nobody enjoys using or paying for a battleship grey app.

WPF also helps you integrate branding into your user experience.  Okay, not important for everyone, but it's more powerful than you may realize.  You can create an immersive environment that frees users of distractions from other applications and yes, even Windows.  You can have your application use to distinctive colors and graphics to make your application stand out, in a way that reinforces your company/product's brand.  And if you're selling software to customers that have their own brand, you can integrate their branding into your application.

WPF lets you build that better user experience by making it easy to do things that used to be prohibitively expensive.  How?  The key thing is that WPF integrates UI, documents, and media into a single, unified platform.  You don't need to learn three separate technologies (e.g., Windows Forms, HTML, and DirectX), and you won't need to bend over backwards to combine them in the same application.  It's not every day you need to put a document on the surface of a sphere embedded inside a button, but that same power lets you build those rich visualizations and great user experience without you having to say, "it sounds like a simple change but it means I have to rewrite the whole program."

Another thing that WPF does is it really allows you to separate designer and developer responsibilities, by helping you to separate look and feel from implementation.  There's a lot of technologies that going to this.  The xaml file format keeps look and feel separate from code, so you can always load it into design tools.  Styling and templating let you change the look and feel of built-in controls without writing code, as well as a way of reusing your look and feel throughout your application.  And data binding lets you separate business logic from its on-screen representation.  Whether you use these technologies to split work between a graphic designer and a developer, or whether you just use them to better structure your code, it helps you write flexible, maintainable applications.

The final point I like to make is that the right time to plan for WPF is now.  Maybe you should be doing 100% of your application development today in WPF.  But even if that's not right for you, you want to start planning for it now.  It's a big business opportunity for you (and for your competitors!), so it's important to think about now.  Think about your business strategy -- WPF lets you build the same kind of applications better, but it also opens up some completely new opportunities.  Talk with your business folks about what kind of new things you can do.  Maybe this is your chance to build a feature that could never be built before, or an application that could never be built before.  Or enter a new market, or leapfrog your competition by an entire generation.  Have that conversation, have a roadmap for what kinds of opportunities you want to go after and when you want to get there.

Part of that planning process is deciding the software/hardware requirements your product will have.  WPF works on Windows XP SP2 and Windows Server 2003, which is the majority of machines out there today. In addition, when Windows Vista ships sometime next year, there will be millions and millions of new PCs sold every quarter (~50 million new PCs per quarter worldwide according to CNET).  WPF apps will obviously work on Windows Vista too. Also, don't forget that by building compelling applications using WPF, you will influence the machines your users choose -- and the more compelling your application, the more you get to influence the requirements.

Another reason to plan is that you want to start preparing your architecture for WPF.  Of course, the more you know where you want to go, the easier it is to create an architecture that gets you there.  But in general, separating your business logic from your UI, writing in managed code, and creating clean interfaces between your components will all have big payoffs as you adopt a major new technology like WPF.

The final reason it's important plan is that you can get feedback to Microsoft.  I'd like to think WPF is perfect, but it's not -- and we need your feedback to improve it.  The nightmare scenario for everyone is your company doesn't look at WPF until the second version, and because we didn't get your feedback, WPF 2.0 is missing that one critical feature you need.  Let us know what you need, so we can make WPF the product you want!

 

So there you have it, my first draft at how to talk to your boss in WPF.  Help me improve it -- where does this argument holds, where does it fall down?  What am I missing that your boss needs to know before he approves your WPF project?  Thanks.