In-Depth
Prepare for WPF Properly
WPF is going to change the way you write graphics applications, but it''s going to take a while before you see it adopted broadly.
- By Billy Hollis
- 06/08/2006
Prepare for WPF Properly
Windows Presentation Foundation is going to change the way you write graphics applications, but it's going to take a while before you see it adopted broadly.
by Billy Hollis
Tech•Ed, June 2006
The last major shift advance in user interface technology happened in the early 1980s, with the introduction of a mouse-driven GUI, first as a research project at Xerox, then in machines such as the Apple Lisa and the Macintosh.
Windows Presentation Foundation (WPF) began life with the code name Avalon, and you might have seen early descriptions under that name. WPF is one of the major elements of WinFX, which is the next version of the .NET Framework. Microsoft is including WinFX with the Windows Vista cycle of products. (WPF will also be compatible with Windows XP, but not with earlier versions of Windows; how compatible it will be with Windows XP appears to be a moving target at this time.)
Before going into more detail about WPF and how it will change how you work, it might be instructive to review how we got to where we are today. The shift to ubiquitous GUIs took a while. The PC world stayed character-based until the early 1990s, when Windows was broadly accepted starting with version 3.0. Browsers extended that sort of user interface to a worldwide audience, but didn't do much to advance the usability of the interface. In fact, HTML, which was designed for hyperlinked documents, still imposes significant UI limitations.
The most important advance of browsers and HTML was the idea that a UI should be dynamic and composable. That is, it should be composed of elements that you can assemble on the fly, and from different sources that are composited into a single UI that is presented to the user. Forms-based interfaces are only now beginning to acquire these important capabilities, but they have problems of their own.
For example, different screen resolutions have caused problems for years. Do you develop for 800x600 or 1024x768? What if the users have bigger monitors than that? Do you simply let that extra space go to waste?
Varying device sizes add to the confusion. Some screens don't even have the normal aspect ratio of traditional monitors. And mobile devices, with their small and varying screens, continue to proliferate.
These problems stem mostly from a single flaw in the traditional GUI: It is based on bit-mapped technologies. That is, all elements of the UI are considered as dots or pixels. We've achieved some scaling of text through technologies such as TrueType, but the underlying design of today's interfaces is extremely constrained by their bit-mapped foundation.
Anyone who has used a vector-based graphics program such as CorelDraw or Adobe Illustrator knows how advanced such technologies are over bit-mapped graphics products. Screen elements are not described as dots; they are described as mathematical curves and positions. You can render the end result onto whatever surface you want, at whatever size and resolution necessary. But the underlying description is independent of bitmaps.
Microsoft is ready to put vector-based graphics right into its next-generation UI. This doesn't match the advancement of GUIs over character-based screens, but it is a big jump.
WPF promises several important benefits. First, you as a developer will no longer have to worry about screen resolution. The UI isn't designed around a particular resolution in WPF, but instead scales itself to whatever resolution is available.
Second, WPF gives you a dynamic and composable UI. Screens can be based on an XML variant called XAML, which might be created on the fly as HTML often is. You also have the option of defining screens in code.
Third, WPF gives you a single UI technology for Web-based and local applications. Microsoft plans a version of WPF, called WPF/e for WPF Everywhere, for platforms other than Windows. This allows browser-based UIs to access many of the benefits of WPF.
Fourth, it enables you to use overlapping screen elements with translucent and transparent effects. This gives you some new techniques for designing your UI that allow background elements to be seen by the user.
Finally, WPF provides a 3D model for UI presentation. 3D is built into WPF at the engine level. This allows completely new navigation and presentation techniques for WPF-based UIs. It will take a while to understand how to use these 3D technologies effectively, but they represent some of the most exciting new capabilities in Windows Vista.
WPF is not without its downsides. For one, WPF faces a tough road to adoption. It requires some serious graphics processing power, which many corporate machines don't have. And, as noted earlier, learning how to use these new capabilities takes a while.
The payoff, though, could be tremendous. Areas such as healthcare, data visualization, and decision-support systems—cases where the UI needs to be flexible, graphical, and responsive—are obvious early candidates for taking advantage of WPF.
Fortunately, the transition ought to be considerably smoother than going from character-based UIs to mouse-driven GUIs. Older interfaces in Windows Forms can be hosted in WPF, and can become one element in an overall WPF system. WPF screen elements can also be hosted in Windows Forms, allowing new WPF functionality to be plugged into existing systems.
For the developer, it's important to assess when and how much you need to learn about WPF. If UI is your primary area of expertise, you should at least start understanding the capabilities right now. If you work in the industries I mentioned, even if you don't primarily do UI, you also should start your familiarization.
If you do commercial software, the capabilities for resolution independence and sheer UI elegance might be a good fit for your product. You need to balance these capabilities against your users' installed base of computers, but you'll certainly need to know enough about WPF to judge when it needs to become a part of your product.
Otherwise, you can wait until we get some better designers. Today, early visual design efforts remain under construction. You'll probably start seeing some reasonably complete beta efforts late this year or early next.
Make no mistake: This transition will be as much mental as technological. Remember those GUI screens that looked like battleship-gray versions of older green screens? You'll be seeing the WPF equivalent for some time to come. To avoid that, understand the major differences as early as possible. Doing so can help you avoid making a similarly clunky approach to WPF as you wrap your mind around the transition.
About the Author
Billy Hollis is the Regional Director of Developer Relations in Nashville for Microsoft, and runs a consulting company focusing on Microsoft .NET. He also speaks at FTP's VSLive! conference and writes a blog for FTPOnline.
About the Author
Billy Hollis is an author and software developer from Nashville, Tennessee. Billy is co-author of the first book ever published on Visual Basic .NET, .NET Programming on the Public Beta. He has written many articles, and is a frequent speaker at conferences. He is the Regional Director of Developer Relations in Nashville for Microsoft, and runs a consulting company focusing on Microsoft .NET.