I started out with Microsoft as contract tester. I had an old customer of a retail store that called me and asked if I wanted to work here. At the time, I had worked in IT groups here, became a dev then left and started a small company. Then I came back to the company, (MS), and I've been working in development tools most of my career here. About 4 years ago I started getting into a more architectural style role and spent several years working on Avalon or WPF. For me, it's been interesting as I actually have this discussion with myself about what is the thing that mainly motivates me. I think the reason I'm at the company and what I'm trying to do is trying to improve user's lives using computers. I've determined that going after developers is the best way to do that because they produce the most number of apps.
It is a really bad acronym that some marketing people came up with. Avalon was started about 5 years ago. It was started as a way to try to address some problems we had with the presentation stack at Microsoft. Over the past about 15-20 years what people wanted to do with computers visually has changed a lot over time. What happened is that we created new stacks, new silos of presentation technology. You had one stack for doing text, one for doing HTML, one for doing 2D controls, one for doing 3D. None of those stacks really worked together well. You ended up with this problem where you'd want to create a game and inside that game you want to put some text. It turns out there's not a good way of presenting text in 3 D this is reasonable and produces good results. And then it wouldn't work for multi languages etc. Avalon was build to try to address that, to build a unified presentation stack that would expand span the realm of scenarios.
WPF really consists of two major components: one a low level graphic engine unless you do 2D 3D text animation, imaging and all that. On top of that is a rich framework of controls that exposes all that functionality and gives you templating and styling like that which you'd expect. Aero is much more of the usage of that engine and framework. Aero is the look and the experience you get on Vista. In fact a large part of those visual effects, the glass effect and the 3D flip features use that core engine from WPF.
Obviously we talked about integration before. That is one of the big problems. Another one comes down to the overhead in creating an app that looks and behaves the way they want. If you write an html app it's really simple to start. But as soon as you want to start doing something slightly more advanced, you then go to one of the language you go to some CSS stuff and you do some styling. If you want some graphics in there you go to another language, you use SVG, Illustrator or Photoshop or something. If you want to then write some script you keep having all these different ways of trying to accomplish the look you want to do. With Avalon we've tried to create a unified programming experience around all these. So you can use XAML if you want to write declaratively. You can use CSharp of VB.NET, Python or whatever language you like if you want to program imperatively against it.
What that did from a developer's perspective is it removed a bunch of those barriers to using technology. If I think the next level op, if I think about the architect and the system designer, one of the big things we did is we tried to create a flexible platform for doing different styles of presentation. Today if you want to build a navigation based app you basically have to do an html and that limits the sets of things you can do. One of the things we did in Avalon was really try to build a stack that lets you do navigation if you want; you can drop navigation into your app. If you want to host it in a browser you can flip a bit and it's hosted in a browser; if you want to do top of the windows, flip a bit and it's up on top of the window. We really tried to make it more flexible for doing your style of apps.
There are two aspects of this question. One of them is the prejudicial use of the word thick client, the evil client. For me is not a question about the thickness of a client but about the user experience you want to offer. One of the problem you had before was that if you wanted to write an app that took advantage of local processing power you were basically faced to writing a large application and using a menuing systems and buttons; all this is a very different experience to what you get when you do a html-based app. With WPF we make it that we can create a windows application that has typographic layout, has text flow, hyperlink, and navigation all the services that you expect to find in the browser. You can leverage all the local processing power.
In addition to that when people talk about thick clients they say" it's so hard to deploy, it's so hard to get it out to that client", there's this large overhead. Another thing we did in WPF as part of .NET 3.0 was these two things: one would be the click-once technology and we extended that in .NET 3.0 to XBPAs or XAML applications. What that gives you is actually the ability to do a browser hosted WPF application using XBAP. Sort of a click-zero deployment of a client application so you actually get that exact experience you expect to find in a browser based app but you still get all the advantages of being able use the underline platform. I think we've created a smooth transition across the realm of options and how you build that. In fact one of the things we announced at the Mix Conference was the WPF/E technology which actually lets you not only go to Windows boxes but you can take XAML content and run it across platform. A multi-environment and a richer rendering engine so we're really trying to create this smooth transition across the family.
If we start at the bottom you have this rendering edge and this graphic system. In the need we have to get pixels on the screen, we know that's the base level. Eventually we have to light on an LCD panel. What we want to do is actually use the graphic processing in it. If you think about a normal video card on a machine there is actually a segment on it that's about the size of half a stamp and that's actually the GDI processor for doing normal 2D graphics. The entire rest of the board is dedicated to 3D processing. For the most part when running on XP on most systems you're basically letting that sit idle until you load up a game. In WPF when we've done is we said we'd push everything through that 3D pipe line including all the 2D graphics until we get acceleration. And how that ends up working is we build a retain mode structure, a graphic system, on top of the 3D pipe line. Within our system you can describe 2D, 3D animation compiling all that down effectively to the graphic processes instructions which can then be sent to the 3D card. So there are a lot of moving parts in there but what it gives us at a top level is high quality, high performance rendering engine that does the entire gamut of technology.
The example I like to think about is text processing. Everybody is familiar with cleartype and how it makes text more readable and if you think about how that works: cleartype works by creating bit-maps based on some instructions from fonts. We have to generate a bit map for every character to put on the screen. And what we do in WPF, we actually generate a path for that. Then in a rasterizer the engine we basically create three triangles for every character and render that with meshes and all that text. Now for those of you who are really into the nitty gritty, there are certain resolutions in which we still generate bitmaps because it's more efficient. But in general you can think of it in terms of "everything gets compiled into 3D triangle".
We're seeing a lot of usage internally; a lot of people are doing experiments right now. It's interesting, as Microsoft is really a collection of a thousand little companies. People like to picture us as this giant company, where you say, "We're all going left now!"…. As Vista is coming out, people really become aware of how stuff is going to fit together and what we can do with it. They start to see stuff like the Expression product line for creating applications and are really getting excited by the capabilities of that. Most of the product groups that I see that are working on new stuff are looking at how to integrate WPF and what they can do with it. Some of the older/mature products are going to take some time to adopt them. It turns out that if you've got 10 million lines of source code it will take you a while to pick up new technologies to any new technology. It's very exciting as people are picking it up.
Avalon team was a fairly large organization, we had a big charter and we were trying to produce a lot of technology that was fairly tightly coupled. We used what we called at the time a "featured team model"; we broke down an org of about 250 people into featured teams of about 20 people each. Each featured team ran fairly autonomously with checks and balances going on and the daily coding process was mostly determined by the individual featured teams. The mix of people on the team was a lot of people from the core groups that used the traditional software methodologies: you have a design phase, you have a coding phase, you do stabilization and then you move on to the next set of things - a more iterative approach to how you do it.
As we continued to move on in that product cycle we actually started doing a lot of experiments with alternative methodology. For example I participated in a security group; we fid a bunch of work to get the troubles going in Avalon. We actually did a full XP style approach. We got everybody together in a single room, we all gave up our offices, we put all the computers together, and we did daily work. We basically didn't have a real distinction between disciplines. We would do code reviews, we do daily scrum meetings. We did all of that stuff. We had really great results and we had a lot of fun. We really enjoyed that as a development process.
Like you said I recently moved to the connected systems division and I'm starting to work on a new incubation project. Within that project we're doing a couple of interesting things. One of which we are doing is a continuing of the agile development process, we're doing daily scrums etc. Another interesting thing we're doing is what I like to call document driven development; so we're actually writing the book that we want to give to our customers, the "book" that explains our technology as we're writing the technology. Instead of saying "here's that test that we want to write" it is how do we want people to think about technology because we're an incubation it's a good fit for doing. We don't have to make the story up later.
One thing is that you don't have to move away from C++. With all the new features of C++, you can use WPF easily from C++. It's a fairly straight-forward transition so there's no huge barrier there. The biggest thing to think about in terms of why adopt a new presentation technology, is really thinking about what is the experience you want to offer to your customers, or what are the features you want in your product, a place where WPF really shines is in creating high quality user experience. If your product is something that relies on having a good user experience and having understood what you're showing them, then WPF is a good fit for that.
It's interesting that in most apps, customers actually touch your product. The interesting thing is that if you have a large project that you have a lot invested in a GDI framework and a standard Win32 framework, the best solution is to start with an incremental approach. You don't have to think about it as an "all or nothing thing". You can use WPF on a small section, you can host it inside of an HWnd and actually have this one bar that's populating with a WPF content. I think it's more where and when you use it as opposed to a big switch over idea.
In the case you're creating dialogues or some sort of wizards, some place where you have a modal effect; it's a great place to inject a new UI framework because you have a very clear crisp boundary. In addition, WPF has better navigation support and user experience for doing those kinds of things. If you're thinking about doing a new look and feel for your application (for example in the new Office product there's a new ribbon style UI and a lot of people are going to start thinking about recreating their user experience to try to mimic that look. That's a great chance to take the chrome of your window and rewrite it in WPF. Really, WPF is going to give you a lot more flexibility and control over the look). One of the classic things people get frustrated about is that scroll bars in Win32 are almost impossible to restyle. In WPF all controls can easily be re-skinned and restyled which gives you a lot of power for that kind of look.
The one major place that I would say is not a good idea to think about adopting WPF is in your unique value proposition of your application. Let me explain what I mean by that, if you're AutoCad and you've invested 20 years in vector drawing engine that does scaling and zooming and 3D and transitions and all that stuff you have a massive investment in that code base. That's going to be a large code-base. It's the thing that makes your app. Trying to replumb your app into that incrementally would be a disastrous thing to do. If you're building a new thing, I would never go to the word team and say "you should place the word canvas with WPF". Maybe I would go to a team creating some new app applications. Don't build a new canvas like Word did. I think there are boundaries there.
The story I like to tell about that question is to look at the "button". Button is one of the most basic controls. In User32, in Winforms, in all the frameworks based on that technology I think there are 10 implementations of a button that all behave differently. The close gadget on a window behaves differently than the ok button in the dialogue behave differently than the scroll bar button behaves differently than the combo box drop down. All those things behave differently. One of the things we did with Avalon was a fully composed system so the same button we've used for an OK button the same one we use in the combo box and the same one we use in the scroll bar.
In WPF.0 and .NET 3.0 timeframe the main thing we did was trying to standardize on the widget level. Make sure all the controls are consistent and compose out of each other and if you customize them then you can do it consistently across them and that was the major focus.
The next thing I expect to see as I go is the dialogue level customization and communality. You can see in the Vista product there's a new thing called task dialogue which is a standard API of the common control library. They give you common dialogue functionality and I expect us to take that and bring it to WPF timeframe.
There are a lot of third party tools, there's the Electric Rain family of products. There are a lot of third paryt products that you can create visuals or illustrator and even Word and export them to XAML. You can use that to create the resources that you want. In terms of building the actual product right now the two main end to end development apps that I know of are the Microsoft expression product line and the early version of Visual Studio. I believe the expression stuff is going to have a CTP that's stable that's going to be out in the near future. I would definitely recommend those two things. The great thing is at the base it's xml and you can load up in your favorite text editor and use Emax or VI and party on.
In terms of changing their process, the number one thing is to hire a graphic designer. It turns out there's a reason why people like magazines, or newspapers. New York Times is a great example of a company who cares passionately about text and they spend a tremendous amount of money in making their paper look gorgeous. They make sure the fonts are laid are correctly, the pictures are laid out correctly, and that makes the presentation of that material much more consumable. I think that is something we as software engineers need to pay attention to. Humans consume the things we create. Hiring someone to create the right visual appeal of the application or the presentation of the information is critically important, as important as having the right architecture. It turns out that the customer doesn't care if you used MVC, Enterprise Services or whatever. They care about the experience they get. That's step one. I would love it if we could get the full employment act for graphic designers.
The other suggestion is this: I think WPF is really the beginning of model driven development or the tipping point. If you look at WPF fundamentally everything is done with databinding, everything is done with data transformation. You don't program to the pixels you don't create data and bind it in you create abstract commands and deal with common routing mechanisms. WPF is the beginning of this idea of separating your app in two things in thinking about data models I want to manipulate, what are the commands I want to act on those and then what's the actual presentation I want to put in. it is something that historically has been around forever. Typically I think the frameworks were so focused on how cool it was that they had MVC they didn't focus on making it a usable thing that you can actually productively develop. I think with Avalon one of our big focus was to get the benefits of MVC style thing, without the complexity or the high science approach to it.
It's interesting that Chris Sells actually works on my team, and we often talk about our books. Neither us would read each other's books because we don't want to pollute our ideas until we both have published. It's very interesting because I think we have two different approaches to how we're thinking about the product. I think about my book as a conceptual reference. The idea I wanted to talk about, what are the main high level concepts you should understand in WPF. I'm not going to talk about the APIs, I'm not going to dive into any options in any tweak that you can make. I want to talk about the guiding principles we used to build the platform. Here's the way we thought this was going to be used and how we thing these things fit together. I think that's a pretty compelling thing but honestly I don't think it's the only book you should have. I think you'd want something that goes to more in-depth in the details, but you should buy mine first and then you can figure out if you need other ones.
In my spare time I'm having some construction done at my house and I spend a lot of time yelling at my contractors. In terms of what I'm reading, I've just started playing World of War craft, so I'm not reading.
No comments:
Post a Comment