Email	Print Reprint
	add to:
	Del.icio.us Digg Google Furl	Slashdot Y! MyWeb Blink

Scott Swigart recently sat down with Mike Henderlight, Program Manager, .NET Client, and Parimal Deshpande, Product Manager for WinFX, to talk about Windows Presentation Foundation (formerly codenamed "Avalon") Interoperability.

SS: Welcome everyone, and thanks for taking the time to talk. Today, we'll be discussing Windows Presentation Foundation (WPF), and more specifically, how Windows Forms, and WPF will interoperate. In my opinion, this is going to be a critical topic in the near future. Most developers realize how much Windows Forms/WPF interop they're likely to be doing, so I'm excited to be talking to you about this. Before digging into interop though, maybe you could take a minute and talk briefly about WPF (formerly codenamed "Avalon").

PD: Scott, thanks for taking the time. We're really looking forward to this conversation as well. First, let's start with WinFX, which is the API for the next generation of Windows-based applications, starting with the Windows Vista operating system, which we will release some time next year. Windows Presentation Foundation is one of the components of WinFX. The goal of WPF is really to let developers deliver a superior user experience for Windows applications, while at the same time, retaining the developer productivity that people are used to, when building applications with the .NET Framework.

Backing up to WinFX, it's built on top of the .NET Framework. WinFX consists of three things: Windows Presentation Foundation, Windows Communication Foundation, and Windows Workflow Foundation. Together, these will let people build the next generation of Windows based applications.

SS: You mentioned WinFX in conjunction with Windows Vista, but WinFX is also going to be available on some down-level platforms, correct?

PD: That is correct. The original plan was to make it available on Windows Vista. As you know, Microsoft is being very transparent with its community through its product CTP and beta programs. This has enabled customers to provide us excellent feedback. One such feedback we got from the community was that we should make WinFX available on down-level platforms as well. We heard the community response, and we've worked accordingly to make WinFX available not only on Windows Vista, but also on Windows XP SP 2, and Windows Server 2003.

SS: You've described WPF as a subset of WinFX. Specifically, it's the presentation portion. Talk to me a little bit about that. What is WPF in specific, and why do we need a new presentation foundation? What's the motivation behind this?

PD: WPF is a unified API for various presentation elements, such as 2D, 3D, sound, animation, effects, documents, and UI. In the past, if a developer wanted to integrate these components into the presentation layer of the application, the developer had to learn different APIs, each with a different programming model. This resulted in increased complexity, which affected developer productivity. In addition, the "stitched-together" presentation layer often did not deliver exactly what the users needed. WPF solves this problem. It's a unified API in the context that it has built-in support for all these elements. It uses a consistent programming model for incorporating all these elements into the presentation layer of the application.

WPF comes with another innovation, which is declarative programming through XAML. XAML is an XML-based toolable markup language. This lets a development team separate the look and feel of the application from the underlying business logic. This allows designers to collaborate with developers to deliver a better user experience. For instance, designers can use specialized designer tools such as Microsoft Expression "Sparkle Interactive Designer", and then collaborate with developers who can develop the underlying business logic. In addition WPF uses vector based graphics rendering, which results in better graphics and presentation for an application. WPF also has other features such as layout, styling, and data binding, which, when you mix with interactivity, enables scenarios such as interactive data visualization.

Putting all this together, you have a unified API for various presentation components, such as 2D and 3D documents, declarative programming through XAML, layout, styling, and data binding, and so on.

The reasons why, we think, our customers, developers, and designers, would welcome this is because it maintains the development productivity that people are used to today with the .NET Framework. Second, this caters to the demands of users wanting better graphics, and better presentations. Third, this enables much better designer/developer collaboration. Finally, businesses can derive value from things like better data visualization, better presentation layer, branding, marketing, integration, and so on.

SS: You described WPF as a unification, which to me is very interesting, because I haven't heard it describe in quite those terms. Let me see if I have the analogy correct. You're saying that the same way that Windows Communication Foundation (WCF) is a unification of remoting, Enterprise Services, and Web services, WPF is a unification of Win32, Windows Forms, and DirectX? Is it a replacement for all of those?

PD: Before I answer that question, let me first clarify what I mean by the term "unified API." WPF is a unified API in the context that it has built in support for various commonly occurring UI elements such as 2D, 3D, sound, animation, effects, documents, and UI. WPF uses a consistent programming model for incorporating all these elements into the presentation layer. For example, if you have a button on a form, you could embed a simple string on the button, or replace that string with an image, or even with a video, all by simply changing a few lines of code. This shows the power of a consistent programming model. That being said, I wouldn't say that WPF is necessarily a replacement for other technologies, such as DirectX. There are DirectX scenarios for high-performance gaming, for example, which WPF does not address.

SS: Once WPF is out, if I'm building a canonical windows application, whatever that means, is it likely that I'll be using WPF entirely to build my user interface for new applications, or is likely that I'll be using a combination of WPF and Windows Forms?

PD: That depends on your scenario, but we fully expect people to use Windows Forms in conjunction with WPF. We have tremendous adoption of Windows Forms today. Developers know how to develop using Windows Forms, and for organizations, their Windows Forms code is an asset. When a company looks at the presentation layer, they might see a number of things in WPF that Windows Forms doesn't provide, and they might ask, "How can I take advantage of this from my existing Windows Forms applications?" We will support that model in the Visual Studio "Orcas" timeframe.

If it's going to be a brand new application, and it's going to release in the Windows Vista time frame, they could look at doing it entirely in WPF, if that's the right thing for their scenario. We support both models, just WPF, and Windows Forms/WPF co-existence. You can make the decision on an individual application basis. You decide when it makes sense for Windows Forms and WPF to co-exist, or when you want to build completely in WPF.

SS: This is a good point to segue into interop. When any company releases a new version of a technology, they're faced with choices related to existing customers. The choices usually come down to migration or interop. In a migration scenario, you provide the customer with some migration tool that will take the old application, database, document, or whatever, and turn it into the new version. In an interop scenario, you don't try to turn the old version into the new version automatically, you just try to insure that they can work together. Mike, I know from your talks and blog posts, that you have been emphatic that Microsoft will not be releasing a wizard where you feed a Windows Forms application into one end, turn the crank, and out pops a WPF application on the other side. Your focus is not on migration wizards. Instead, the focus is going to be on really good interoperability. Would you take a minute to talk about that?

MH: Sure. The statements you're making are exactly correct. The bottom line is, we're trying to learn from what we've done in the past, and from talking to our customers. And, even though some customers may say they want the migration approach, if you really dig into that, it's really hard to get that right. Our message to customers is that you need to be very conscious about moving to a new technology, and not think of it as some afterthought. You really don't want some little wizard making big decisions for you. You want to make good, strategic, decisions with your code base. That's one reason why we decided not to take the migration approach. In looking at this, we could have done some of the migration wizard stuff, but we just think it's the wrong approach.

With our approach, we think it makes more sense to let customers fully leverage their existing code base, and move forward to the WPF world at their own pace. What customers wouldn't want to hear is that they have to make a choice between Windows Forms and WPF; they would not want to be told that they have to rewrite the entire application to take advantage of any of WPF. The approach we're trying to take is, "You don't have to rewrite. You can move at your own pace, and decide what features and functions you want to keep in Windows Forms, and just use WPF in the areas of your application where it really makes sense."

SS: And I just have to chime in and say that as a developer, who uses these technologies, I'm incredibly pleased that this is the direction that you've decided to go. When .NET came out, it did have a partial interop story with COM, but it's not like the entire .NET Framework was directly callable through COM interfaces. A lot of companies, if they wanted to use .NET at all, were faced with exactly the kind of choice you mentioned. They had to ask, "Should we migrate the entire application to the .NET Framework so that we can use these new .NET features?" The problem is, you then have to try to calculate the ROI of doing a big migration. You need to estimate the risk of doing a migration. You need to budget the time to do the migration, which will just get the application working in .NET the way it worked in unmanaged code. You need to invest heavily in training your C++ or VB6 developers in .NET so that they have the skills to actually pull off a migration.

By going with an interop approach, all that FUD goes away. There is no risk of a failed migration. There's no migration ROI calculation. You're not allocating months of developer time just to migration, which may not add any new functionality to the application. Instead, you just start using WPF immediately, with your existing application. You can learn WPF very incrementally, because you only need to focus on, and learn, the specific pieces that you're adding on to your application, so there isn't this huge up-front training requirement.

I'm behind you 100 percent on this approach.

PD: And that's exactly what we're thinking as well. We think that by going with the interop model, what we call the co-existence model, we're empowering developers to incrementally learn WPF, as an option. They can learn it at their own pace, and that provides a much smoother transition than forcing an abrupt migration.

MH: The other thing that's important to remember is that when we show WPF, a lot of times we demo something like turning a Windows Forms text box into a WPF text box. That's just for illustrative purposes. WPF isn't really about just swapping out Windows Forms controls for WPF controls. It's really about finding new ways to add value to your application, such as finding new ways to visualize data, and do things that just weren't possible with a Windows Forms model. Or, to do things that wouldn't be feasible if you had to write all your own bare-metal visualization code. We're trying to get people thinking about adding WPF functionality to existing applications, but not get stuck thinking, "Why would I swap out a Windows Forms control for a WPF control?"

SS: One other thing. Have you locked down the list of initial WPF controls? Because for me, looking at it from the outside, it looks like there's going to be some overlap between WPF and Windows Forms controls. Is it accurate to say that there are Windows Forms controls for which there won't be a WPF version, and vice-versa?

MH: That's exactly correct, and there are a couple of reasons for why that's the case. You have to keep in mind that WPF is a new technology and it's very important that they get the core pieces of WPF right. They have to get the core right first. They're not going to spread themselves too thin by trying to have control parity with Windows Forms. Windows Forms has been in existence for three releases now. There's no way they can initially have control parity with it. I think it's highly likely that you'll augment the control set that WPF provides by continuing to use Windows Forms controls, or third-party controls. We have a very rich set of third-party controls out there, and it's critical that those controls continue to work and interoperate with WPF.

SS: And do you have any specifics at this point? Can you list some controls that will be in Windows Forms but won't be in WPF? It seems like this is something important for people to be considering today. As people build applications, they should know which controls they're going to be carrying forward into WPF versus switching to WPF controls that that are clearly superior.

MH: Sure, there are a few things. For example, we think that the new DataGridView control that shipped with Version 2.0 of the Framework is a really great control, and we don't think there will initially be a control like that in WPF, so we think that people who need that functionality will continue to use the Windows Forms control. Furthermore, think of things like user controls. Think of customers who've spent a lot of time developing very complex composite controls. They don't want to be forced to unravel those and figure out how to re-create those in WPF.

On the WPF side, it goes back to thinking about ways to visualize data in ways that you just can't do in Windows Forms today. Think about the graphics capabilities, the 2D and 3D capabilities, and the high performance capabilities of WPF, and how that would let you visualize data in new ways. I think that those are some of the areas where the two worlds will contribute to great applications.

SS: Drilling into interop then, what are the interop scenarios that are supported?

MH: This model is all about coexistence. On a single Windows Forms form, you can have Windows Forms controls and WPF controls. On a WPF page or window, you can have Windows Forms controls and WPF controls. We also support a mode where you can have a Windows Forms or WPF application that wants to show a modal or modeless form built using the other technology.

SS: What if we go back even further? You've mentioned data visualization a number of times, this makes me think that something like Excel might be the poster child for WPF interop. If the Office team wanted to enhance Excel, which is mainly a C++/Win32 app, with WPF, what would that take? What about a VB6 developer? Can they use WPF?

MH: Yes, you can do that. I mostly focus on WPF and Windows Forms interop, but there are others focusing on unmanaged interop. In fact, I think there have been some case studies inside of the company where we've taken something like Solitaire, and moved it over to WPF and WinFX. If developers have a pure C++, unmanaged applications, and they want to leverage WPF, they have an interoperability model as well. It's using a base technology in WPF, which consists of two classes known as HWndSource, and HWndHost. These are the things that we build on top of for Windows Forms interop. Those allow us to build the hosting controls we need for interoperability. As for VB6, we're not currently building anything that would let you host WPF controls in VB6. However, VB6 developers can build ActiveX controls and host them in WPF.

SS: What about the other direction? Can WPF host ActiveX controls?

MH: Yes. We do have plans, and support, for hosting ActiveX controls in WPF applications. Windows Forms can host ActiveX, and that lets us leverage that existing ActiveX hosting model in WPF as well.

SS: I know that when Microsoft comes out with new technology, they typically recommend that you use it, and use it a lot. But, I know a lot of people like to sit back and watch Microsoft, and see exactly how, and if, you use your own technologies. I know that was an issue when .NET first shipped. People said, "Okay, Microsoft, let's see what you build in .NET. Let's see what you do with existing unmanaged applications as you move them forward." Are you getting interest from the other Microsoft product teams? You don't have to name names, but does it look like other Microsoft product teams are going to leverage WPF?

MH: Yeah, in fact, I've been quite busy lately trying to entertain requests for meetings from other product teams that are jumping on the bandwagon. They're very excited about interop, because they have exactly the same issues as our external customers. They have a large, existing code base, and they want to find a way to embrace this WPF world. We're just like everyone else in that we can't rewrite our applications whenever a new technology comes out. They see this as a wonderful opportunity to leverage WPF. There are four or five product teams that I'm already working with, trying to understand what their needs are, to make sure we consider them, just like we consider other customers that are interested in this technology. That helps us make sure we're building the right technology for everyone. We expect more product teams to come to the table as they learn more about these capabilities that we're producing.

PD: I absolutely agree. I spend a lot of time meeting internal Microsoft product groups, and hooking up WPF PMs (program managers) up with internal prospects. It's interesting, Scott, that the questions that you're asking are the exact same questions that we get asked from the internal product teams! They are showing a lot of interest in WPF, and they're getting the same answers that we're giving you. Over the next few months, hopefully, we'll have success stories from some of our internal dog fooding of WPF.

SS: If you're mixing and matching WPF and Windows Forms, how seamless is it going to feel? Is it going to feel like you're constantly switching from planet WPF to planet Windows Forms, or is the terrain going to stitch together a little more smoothly than that? In specific, let's look at a scenario like data binding. If you're data binding to a Windows Forms control, will it be done one way, and if you're data binding to a WPF control, it will be completely different?

MH: Our ultimate goal is to make this as seamless as possible. Over time, we have to figure out how much of that we can do. These are different technologies, and there are different things that each technology can, and can't, do. Our goal initially is to make it very seamless so that it does all feel like part of one application, and not like you've taken a leap to another planet. In terms of the database example, one of the things that we're working on is to make sure we have a story there for a seamless model. One thing in specific is making sure that we can share a single data source across both models. We've been able to demonstrate binding both your Windows Forms and WPF controls to a single BindingSource object, and it just works. We think this is what customers are going expect. With Whidbey (Microsoft .NET Framework 2.0), we're releasing the BindingSource object, and we're telling customers this is what they should be using, and we want to be able to say that you can take that same BindingSource, in a hybrid application, and data bind your WPF controls to it, and it just works.

SS: I think you're right. I think data is such a key scenario, and I agree that it's very important that you be able to bind both kinds of controls to the same sources. I think that's pretty strong.

MH: And one of the things that I'm trying to do is not just come at it from a Windows Forms perspective, but from the perspective of, "This is how we teach customers to build applications today." So for all the things that work in Visual Studio 2005, we want you to be able to keep leveraging those. For example, Visual Studio 2005 lets you use a new config system for your applications. Once people learn that, we don't want them later to have to learn some completely new system. Our idea is to be clear that everything you invest in learning Visual Studio 2005, you can keep going forward, and just sprinkle WPF functionality on top of that.

SS: Another thing that seems very different between WPF and Windows Forms is eventing. If I understand it correctly, in WPF, events can tunnel in, and then bubble back up. That's very different from Windows Forms, where "The Control" gets "The Event". First, am I understanding this correctly? Second, what happens when you mix and match the two, and you have something like a Windows Form control sitting on a WPF form? How do those eventing models hook up?

MH: That's a really good question. You do have it basically right, in that WPF has a richer eventing model. WPF has this notion that events can be routed. An event can be bubbled event, or a tunneled event, meaning that they can go up or down in the hierarchy. WPF also supports direct events, like in Windows Forms, where "The Control" gets "The Event". Events can even structured so that they have a particular routing strategy. Not all events bubble, and not all events tunnel. In Windows Forms, on the other hand, they're pretty much all direct events, meaning that the event goes to a specific control, and doesn't tunnel or bubble.

We actually spent a lot of time thinking about this. One thing that we thought a lot about was, do we want to propagate this event model down to the Windows Forms space? For example, if you have a WPF form, on that form you host a Windows Forms control, and then beneath that you have other WPF controls. Should that Windows Forms control be involved in a bubble or tunnel? We spent a lot of time thinking about that, and first of all, it was going to be very difficult to do that. Second, it was bringing a foreign concept in to a Windows Forms control, that the control wasn't designed for. Our current strategy is that we'll treat it as a black box. We're not going to try to route events from WPF controls into Windows Forms controls, where it doesn't make sense. And the converse is true also. We're not going to try to artificially pump things out of the Windows Forms controls into the application space, where it doesn't make sense.

SS: In other words, letting each technology work the way it naturally works....

MH: That's exactly correct. Each individual technology was written assuming those models, so it makes sense to stay true to those eventing models. We write the glue around that, to make sure those models fit together in a way that feels right. There are some things we had to do. For example, we did some work around keyboard handling to make sure that things like tab order, navigation keys and focus management work right in a hybrid application. But, outside of those specific instances, we're working to keep the eventing models pure.

SS: Is it too early to talk about IDE tools? I know that Microsoft has thrown out names like Orcas and Cider. Sitting on the outside, I'm unclear about how these match up. One scenario I could envision is having one unified development environment, where maybe I'm working on a Windows Forms application, but I can drag WPF controls on to it. Another way I could see it working is, if I'm working on something that's Windows Forms, I've got this Orcas development environment that I use, but when I want to work on WPF functionality, I have to open up a separate Cider development environment. This would feel like the old days of C++, VB6, and Visual Interdev all running separately. Which view do you think is more accurate?

MH: Let's clarify that for you just a bit. If you think about tools for specifically for WPF, there's Cider, but there's also one that's codenamed Sparkle. Sparkle is being built to run outside of the Visual Studio IDE, but it's for designers, for graphic artists, not developers.

Now, think about what's inside of Visual Studio. Think about the Windows Forms designer. It makes sense that inside of the same Visual Studio, that there's a designer like the Windows Forms designer, except that it targets WPF windows and controls. That's what the Cider project is all about. Think of that as the visual designer for WPF. It will ship in Visual Studio as part of the Orcas release. Orcas is just a codename for the next release of Visual Studio, and it's all about letting you build applications that can target existing technologies, and also target WPF, and really all of WinFX.

Also, we're planning on extending the functionality of the Windows Forms designer so that you can drag and drop WPF controls on to your Windows Forms form, and it will just work. We're going to try to provide both sides of the equation so that our customers have a good visual design experience for Windows Forms, WPF, and hybrid applications.

One other cool thing we're working on is a whole workflow experience that integrates Cider and Sparkle. This will let you continuously pass your XAML files back and forth between designers and developers, such that you can have this iterative cycle between graphic design and coding. That's been really difficult to do to date.

SS: It seems like this is really an evolution of the ASP.NET model. One of the things that I love about ASP.NET is a declarative language for building the user interface. I think that just makes so much sense. You literally just nest controls within the declaration of other controls, which is very visual and logical. In Windows Forms, you have this imperative model, where you declare controls, and then have to add them to the controls collection of other controls, and you can't just scan through the code and have the UI hierarchy jump out at you.

ASP.NET also gave you the separation between the presentation file versus the logic file. But, one of the limitations of ASP.NET is that Microsoft always said, "Oh, just give the .ASPX file to the graphic artist," but Microsoft never provided an ASPX editor for the graphic artist. And, the main graphical tools don't have any idea what an ASPX file is, so you end up with Graphic artists working up a UI, dumping it to the developer as static HTML with images, and then the developer has to do something like a skin graft to get that UI into the ASPX file. The Web developer, the guy who's supposed to be writing code, ends up needing to worry far too much about HTML, CSS, and browser compatibility.

PD: And here, we're providing that tool for the graphic designers. With Microsoft Expression "Sparkle Interactive Designer", which is a product in the Microsoft Expression Studio, the interactive designer can create the look and feel, including a lot of the interactivity, such as mouse-over effects. The designer can hand that to the developer, and the developer can just write the code behind it. Both Sparkle and Cider use the same MSBuild system, so they're compatible in a way that allows that kind of collaboration.

SS: Looking at it a little from the Sparkle side, and looking at the kinds of things that WPF enables with little or no code, and considering that it's vector based, in some ways, it looks like it overlaps with Flash. If you were going to put Flash and WPF side by side, what do you think are some interesting points of comparison?

PD: Actually, we don't compare WPF with Flash. When we think of Windows Presentation Foundation, it's a presentation layer for Windows, which, along with other Windows Vista technologies, provides a "better together" user experience. WinFX, of which WPF is one component, is the platform that offers a great user experience. So we really don't internally think of this as a comparison to Flash.

SS: How about when you get into something like WPF/E, which is Windows Presentation Foundation Everywhere? There seems to be a lot of stars that are moving in alignment. You have the ASP.NET team working on Atlas, you have WPF/E....

PD: The goal for WPF/E is to provide reach for Windows Presentation Foundation to other platforms, such as Mac, and devices. Right now, we're still working out exactly what are the WPF/E scenarios that we'll support. So, at this time, we don't really have any additional information to share about WPF/E except that its goal is reach across other devices.

SS: I have a question for you Mike, this is a follow up to something that I saw you blog about the other day. One of the things that I hear from the people is, "Well, it's nice that you can make a rotating button with full motion video on it, but honestly, my life is forms over data. I do line of business applications, or corporate applications. What does WPF really do for the kinds of applications that I develop?" Like I said, I know you've already blogged about this, but I just thought I'd give you the opportunity to respond to that kind of statement here, as I think it's a frequently asked question.

MH: The way I would answer that is that while you certainly could try to migrate your Windows Forms application to a WPF application, I really don't see that much business reason for doing that. And specifically what I'm talking about here is a control-for-control translation. There's not a lot of ROI there, with the exception that maybe its easier to skin your application. And actually, skinning is something that our Windows Forms customers have asked for, for years. And WPF does make it very simple to style an application. But, outside of some little things like that, there's really no benefit to doing a strict translation to WPF.

The challenge really is trying to get people thinking about applications in new ways. So, for that bank application, that is a Windows Forms application today, with a bunch of ListView and DataGridView controls, I've already seem some customers start to think outside of the box, and do all kinds of 3D visualizations that relate the customer with their data. Think about a loan process that may have some visual that shows where you are in the process. You start drilling up and down, and rotating these things around, and it gives you a much more interactive way to work with the data than flat forms. If you want to keep an application forms based, then there's not a lot of value in WPF. But where I really see the opportunity is that WPF makes it easy to visualize information in much more meaningful ways.

PD: When I talk to customers, and even our LOB product teams within Microsoft, this is also a question we get. They ask, "Why would I want to move my code base to WPF?" The thing I've realized is that until they see it, it's hard to understand the kinds of user interface paradigms that are now possible with WPF. My answer to them is usually, "Show me your application." If it's just data entry, which is very common, then I look at how they're using the data, and talk about how they could maybe visualize it. Maybe they could be showing forecasting, or other data relevant to supply chaining, in a way that makes the important data stand out. They might be able to easily get a lot of business intelligence value that would otherwise be hard to get, and this enables better decision making.

SS: Let me say that back in my own words, to make sure I've got it. For the companies that are looking at WPF and saying, "Why should I care?" the things they should look at first are places where they're charting, reporting, or otherwise visualizing data. Even if it's just showing it in a grid today, if data is being presented to human beings, they should ask themselves, "Is this data presented in a way that lets the person quickly derive meaning from it?" In the past, you put it in charts and grids, because that's what you had to work with, but with WPF, it becomes a little easier to render what your minds eye sees, without needing to do bare-metal graphics programming.

PD: Right, so anything that's data intensive, like planning, flowcharting, forecasting, charting, data entry with a business intelligence component, I think WPF with Windows Forms interop has great potential to improve the application.

SS: And then beyond that, Mike, I think what I heard you say is maybe you start to rethink the whole application. Maybe, instead of customers showing up as names in a list box, they show up as icons or images, with properties that fade in when you mouse over them, because that's just so easy to do now. It sounds like we're all going to be reading a lot of Edward Tufte. Things that would have been very hard to even prototype in Windows Forms, you can now mock up, or even code up in WPF in practically no time.

MH: That exactly correct.

PD: Over the next year or two, companies will start using this interop story, and they'll realize, "Wow, this is pretty powerful. It's not only that it looks good, but there's significant business value." A tipping point will come, were suddenly LOB developers will say, "I don't want to live with--just good enough--user interfaces. I can get better user experiences in my application. The applications really do the job, and they're easier to use." I see a tipping point where people will really start to feel that there is business value in the user experience, be it ease of use, be it differentiation, or be it business intelligence. At that point you'll see maturation, because the whole bar for user experience will be higher in the market.

SS: To me, it's 1996 all over again. The Web came out, and there were all there things that you could do with it. On one hand, people did some very interesting and creative things. On the other hand, you saw blinking text and animated GIFs all over the place. If I had to look in my crystal ball, I think WPF will give people the opportunity to experiment visually, at a level that they never had before. I think you're going to see, on one hand, some really heinous things come out....

(laughter)

PD: Absolutely. That's one of our challenges in the next year or so. We're delivering something that's incredibly powerful. With great power comes great responsibility.

(laughter)

We're thinking about how we should provide guidance to our customers so that they know exactly how to use this in a way that doesn't result in something heinous, as you say. That's something that you're going to see us working on, providing guidance, and templates, and styles, and those sorts of things.

SS: But on the other side, I'm quite confident that you're going to see people use this technology that you've invented in some incredible ways that you never imagined. And when you see some of these things, you'll think, "Wow, that's the coolest thing I've ever seen, and I would have never thought of using our technology that way."

PD: In fact, at PDC, in December, we saw just one of those things. One of our customers said, "Let me show you a demo based on your technology, and Powerpoint." And, we thought, "Powerpoint? What could you possibly do with WPF and Powerpoint?" It was hard to imagine what it might be. And he showed us a quick demo where he was making slides using XAML. It was really amazing.

As the WPF GPM once said, that's the joy of working on a framework, rather than a product. No matter how many PMs we have working on it, and envisioning scenarios, there will always be scenarios in the market that we never envisioned.

SS: And I think out of that, whole new user interface metaphors might appear, much like they did on the Web.

MH: That's what makes this business so exciting.

PD: And it's a great learning opportunity for all of us. I'm traveling a lot in December to customers, and every time I go to a customer, I learn something new.

SS: If someone wants to get started with this today, what should they download to get rolling?

MH: The really should just download the latest WinFX CTP, which includes the WPF functionality, and the interop DLL. This installs on top of Visual Studio 2005. Right now the interop technology is in a single DLL that you'll find in the WinFX CTP in the SDK. For right now, it's put there really as just a convenience. We put it there so customers can work on this technology, and give us some feedback. Ultimately, the interop code will not ship with WinFX. It will actually be taken out of the WinFX SDK, and be included in some other ship vehicle that's more appropriate for the Orcas release. We're working on those plans right now, and it's not certain what that ship vehicle will be. But again, today, you should just download the WinFX CTP, and install it on top of Visual Studio 2005.

PD: From a timing perspective, we just had a November CTP of WinFX. In December, we'll have a Windows Vista CTP, which will include WinFX. And the plan right now is to have a CTP every other month. We'll keep providing things to the community so they can start prototyping, and also giving us valuable feedback, which we always appreciate.

SS: Any final thoughts for our readers?

PD: WPF is the strategic presentation layer for Windows-based applications. However, we know that Windows Forms has wide adoption today, and we want to make it very easy for our customers to use both, and transition from Windows Forms to WPF, where it makes sense. This interoperability functionality will be released in the Visual Studio Orcas time frame. Please, use the CTPs today, and give us feedback, so we can improve the product.

SS: Guys, thanks for taking the time to chat.

Scott Swigart is consultant specializing in convergence of current and emerging technologies. Scott can be contacted at scott@swigartconsulting.com.

RELATED ARTICLES Q&A: Software Testing In A Virtualized World Secure Software Needs Careful Testing -- And Lots Of It Securing the Java Core Petascale Tools and Genomic Evolution Legal Compliance: Open Source and Quality Assurance		TOP 5 ARTICLES No Top Articles.