Staffing a WPF + Silverlight project - wpf

If staffing a "Silverlight / WPF business app" project would you include a team of graphic designers?

In order to staff a Silverlight project its generally a good idea to fill three roles:
UX
Creative
Technical
UX is
typically a front loaded activity
that operates primarily during
analyze and design and whose
deliverables input into build.
Creative gets brought in during design. Creative has two basic roles: Visual Designer and Interaction Implementer. A Visual Designer will be heavily utilized during the design phase and will live in tools like Adobe Illustrator or Expression Design to construct visual assets. A Visual Implementer will be most heavily utilized during the build phase where they will work side-by-side with the technical team to integrate the visual assets into the solution. Ineraction Implementers will live in Expression Blend.
Technical is of course utilized the heaviest during build but, as usual you should bring your Technical Architect on during Plan & Analyze to help steer Functional, UX, and Creative towards feasible solutions. Developers will live in Visual Studio and Expression Blend.
Depending on the skill sets of your team you may have some cross over personalities along the Implementer/Developer boundary. As developers get more and more savvy in the ways of Expression Blend, I think we could see this role as a secondary or tertiary skill set for many developers.
Generally, its a good idea to bring on UX & Creative resources if you are trying to achieve some higher order levels of user experience but it is not required and I would say in your case specifically it would be a "nice to have".
Silverlight is a highly viable development platform for building standard line of business applications. Silverlight is not just about flashy graphics. Its about building web applications that have all the features modern users have grown to expect with faster time to market and lowered maintenance costs. Oh, and if you want to add some piz-azz with all the spare time you have...you can do that to. :-)

I don't know if I would include Graphic Designers. I would look for UX (User Experience) Designers.
A UX Designer will have the skills of a Graphic Designer with an understanding of User Interface Design.

Here is something that I wrote as JDs for staffing a Silver light Project.
UX Designer Profile
Ability to visualize and create
user experiences, and to translate
them to UI designs using Expression
Blend
Excellent understanding of XAML and
capabilities of Silverlight
Excellent understanding of creating and applying styles and templates
Ideal
candidate will have been working with
Silverlight 1.0 since its inception,
with examples showing level of
expertise with an understanding of
enhancements made with 2.0 and 3.0.
Silverlight Architect
Ability to guide the team by putting in place the required tools and frameworks (end to end) for Silverlight specific projects
Experience using Expression Blend and Visual Studio for Silverlight application development
Good understanding of XAML
Styles, Triggers, Observable Collection, Data Binding Methods, Model View View-Model (MVVM) pattern, Navigation patterns
XML and LINQ within Silverlight
All aspects of Silverlight framework including DLR, Isolated storage etc
Understanding about essential application blocks like Composite application block (Prism)
Excellent understanding on using RIA, WCF services and ADO.NET Entity framework services with Silverlight
Excellent knowledge of development within .NET 3.0 & 3.5 Framework
Must understand the fundamentals of software development, including best practices and OOP design patterns. An understanding of cross-browser Front-end development issues is important
Knowledge about 3rd party UI libraries
Familiarity in Live Mesh technologies
Silverlight Developer
Experience using Expression Blend and Visual Studio for Silverlight application development
Excellent C# and XAML skills
Experience in using MVVM
Strong JavaScript skills
Working knowledge of development within .NET 3.0 & 3.5 Framework

To me, it depends on the project and the quality of the UI you are looking for. For a lot of internal projects, hiring on a full time graphics designer might be a bit overkill. If you are creating an external facing website/project, then you should definitely bring someone with user design experience on board.

I think the job position title du jour is 'Interaction Designer' - they are the ones who speak the lingo of user experience, usability, etc. In other words, the ones who are experts in 'interaction design.' You want a team of them instead of graphic designers.
Obligatory wikipedia article on iteraction design: here
Graphic designers are nice, but unless you are building an OS, you don't need a team of them. Just a few to build mock-ups in Blend, or Photoshop (and let your developers translate photoshop images to XAML with Visual Studio)

Of course - theoretically, they are supposed to use Expression Blend Studio, but that doesn't work very well, so you need to find a techy UI person who can work in VisualStudio. Always have UI people if you are building UI though - having professional looking apps is just as important as having apps that work well.

Without splitting hairs about the job description I would answer a huge Yes to this! Give your developers the freedom to focus on the code they're good at and get an application that looks incredible at the same time. This is a huge win.

Related

How to convert old project to WPF

We have lots of project developed using .net 2.0 version if I want to convert those project to WPF then what will be the approach. Please discuss in detail.
to let the migration to WPF easy, be sure that your existing code doesnt contains a high coupling between GUI and your Business layer, if it's the case the most important step is to refactor your existing code, so your GUI code will contains only what's related to GUI.
And after this step the part of your project to migrate will be not the big one, it will concerns only the GUI logic.
When I did this kind of migration from winform to WPF , we spent more time to remove coupling between GUI and other layers than to migrate the GUI layer, due to high coupling betwn GUI and other layers.
Having gone through a similar exercise I'll tell you that it can be done but there are some challenges.
Step1: Just for clarification when we say WPF some people mean Silvelright / web. WPF is not Silverlight so you need to clarify I want to migrate existing applicaitons to WPF thick client applications. Since you stated WPF I am assuming you mean thich client/windows based applications so we'll go that route. (I'll mention SL at the end)
Step 2: Evaluate your projects from the code level for the most part refactoring the code is fairly easy. Since you are migrating from .net 2.0 to .net 4.0 I would really look at how many of your classes are defined, and see what can be refactored or in some isntances completely redesigned. THis leads us directly into step 3.
Step 3: Pick a design pattern. One of the tricky parts is coming to terms with a new design patterns such as MVVM for WPF. More than lilkely you will want to strip out and redesign the entire UI. As a result you will also want to utilize a proper design pattern (MVVM) or some flavor of that. This will also tie back to step two as some of your code will need to change to support your design pattern.
There are a ton of resources online for MVVM as well as UI development. If you are looking for reading materials I would look to WPF 4 unleashed as well as WPF illustrated. Both are good reads to help you get up to speed on the UI components how they work and the proper approach to using them in a project.
Get familar with .net 4 and the use of collections, types and of course the numerous new classes for wpf.
Disclaimer: You can in many instances create a WPF application usign tradition winform layout and practices. Whether this is right or wrong is a matter of opion of the developer. My personal opinion is that yes you can forego learning new design patterns and use a winform approach but you will not gain the full benefit and capabilities of the framework using this approach.
And finally if you are planning to migrate these apps to the web (silverlight) your work will be a little more of a challenge. Silvelright does have a little higer learning curve and there are a few more rules (security, asynchronous calls, web services etc) that must be learned, and followed. I have foudn that in creating a migration that it is easier to migrate from Siverlight to WPF that vice versa. As Microsoft continues to improve Sivelright I think we will get to the point to where the code is interchangeable between the two patterns however right now it's not there.
Conduct a search online but here are a few links to help you get started:
Scott Guthrie (Silverlight) http://weblogs.asp.net/scottgu/default.aspx
Josh Smith (WPF MVVM) http://joshsmithonwpf.wordpress.com/
best of luck

Is WPF a good technology for software engineers to learn?

So I'm seeing a lot of C# software engineer job ads asking for lots of experience with WPF lately. I have not worked with WPF before, but it seems like it would be more of a designer oriented technology, not necessarily something that a programmer would need to know in depth. Now, I know there are a lot of cross-cutting skills (what programmer doesn't know HTML) but I'm wondering how much emphasis, if any, I should dedicate to learning WPF.
I know this is a little subjective, but I'd like to get people's thoughts on the importance of WPF from a developer's perspective.
If you want to create Windows UIs, you should learn WPF. It has nothing to do with designers, it's a UI framework, just like Winforms (only way better).
WPF is important if you are writing any new UIs for Windows in .NET. It is newer than windows forms and actually less people have the skill, and it is just reaching the point where companies that are currently using Windows Forms are switching to WPF or Silverlight, so the demand for WPF developers is increasing.
Paul Betts was a little off when he said: "It has nothing to do with designers.."
It has a lot to do with designers. WPF was architected with the designer heavily in mind. However, that doesn't mean a developer doesn't need to know WPF.
Sure you can just use WPF as a UI framework just like Windows Forms but you are losing out on the main benefit.
WPF was architected in a way so that the designer and the developer can both use the UI framework for what they do: designers design, developers develop.
A designer can jump into Expression Blend and make a really slick application design and even design a lot of application "movement". The designer can do quite a lot and quite quickly.
The developer can create business logic and provide data and integrate the business logic with the WPF. You can manipulate WPF using binding, which means no code-behind and design patterns such as MVVM are based on this, but you can still use code behind to manipulate WPF elements.
Self training sites:
http://windowsclient.net/learn/videos_wpf.aspx
(The next two sites are both "in
progress" training courses, meaning
they aren't finished)
http://www.wpfsharp.com/learning/wpf-self-training-course-for-developers/
http://www.wpftutorial.net/LearnWPFin14Days.html

WPF versus Windows Forms [duplicate]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
Most restrictions and tricks with windows forms are common to most programmers. But since .NET 3.0 there is also WPF available, the Windows Presentation Foundation. It is said that you can make "sexy applications" more easy with it and with .NET 3.5 SP1 it got a good speed boost on execution.
But on the other side a lot of things are working different with WPF. I will not say it is more difficult but you have to learn "everything" from scratch.
My question: Is it worth to spend this extra time when you have to create a new GUI and there is no time pressure for the project?
After three months of trying to hammer out a line-of-business (LOB) application on WPF, I reached a point of considering turning back to Windows Forms for my project, and in researching other people's opinions, came across this thread...
Yes, WPF is a brilliant technology and it has benefits that span far beyond mere eye-candy... the templating and binding capabilities are great examples. The whole object model offers more flexibility and broader possibilities. That doesn't, however, make it the defacto platform for future LOB applications.
The "problems" which WPF solves in terms of separating GUI from business logic aren't problems which can't be readily solved in Windows Forms by simply starting with the right architecture and mind-set. Even the object-path binding capabilities of WPF can be reproduced in Windows Forms with some very simple helper classes. The data template capabilities of WPF are very nice, but again they're nothing that you can't simulate in Windows Forms on those rare occasions when you absolutely don't know exactly what objects you're going to represent on any given part of the screen.
Where Windows Forms races ahead is in terms of maturity. You can't swing a dead cat on Google without hitting some blog where someone has solved a Windows Forms problem for you. WPF, on the other hand, has comparatively less learning resources available, fewer custom controls available, and hasn't had as many of its teething problems solved.
At the peak of making a WPF vs Windows Forms decision has got to be the maturity of the development environment. Windows Forms editors are slick, responsive and intuitive. Feedback about errors gets to you instantly, the solutions are usually obvious, and the compile->debug->edit cycle in Windows Forms is very quick.
WPF applications, on the other hand, have comparatively pathetic design time support, with the design view all-too ready to chicken out at the first encounter of an error, often requiring a project build after the fix before the designer is willing to kick in again. Drag'n'drop of components from the toolbox might as well not be supported, given the vast range of circumstances under which it either doesn't work at all, or yields completely unintuitive results. Despite the promise of the WpfToolkit, there still isn't a usable DataGrid for WPF that yields any kind of resonable performance or design time friendliness.
Debugging WPF applications is a bit like the old ASP.NET debugging paradigm... hit F5 -> wait -> launch -> error -> stop -> fix -> hit F5 -> wait -> launch -> error -> groan -> stop -> fix -> hit F5.... All XAML which your program is running is locked, and tracking down XAML specific problems is often tedious.
The bottom line, simply put, is that the development tools for Windows Forms are going to have you banging out front-ends in a fraction of the time of a WPF application... especially if you're creating master-detail grids or spreadsheet like interfaces, which most LOB have. With Windows Forms, you start with 90% of the work already done for you.
I'm a huge fan of the WPF architecture. I just wish the design-time tool-set didn't feel like a pre-alpha debug-build.
Edit: This answer was posted about .NET 3.5 + Visual Studio 2008, but .NET 4.0 with Visual Studio 2010 ships with a WPF data grid. While many improvements have been made to the new WPF development experience, my answer here remains unchanged, and I'd like to add the following suggestion:
If you're in a rush to do RAD development, go with Windows Forms. If you're looking to produce a well architected, maintainable, scalable, resource firendly, multi-user Line-Of-Business application, consider ASP.NET MVC + HTML 5 + jQuery... My projects with these technologies have resulted in better outcomes, sooner, for my customers. MVC offers all of the same templating that WPF does, and jQuery enables animations and complex interactions. More importantly, an ASP.NET MVC + jQuery solution doesn't require your end users to have modern desktops with decent graphics hardware.
I'm seven months into using WPF on what has now become a core system for my customer, and I'd like to share some more thoughts with you about the experience of learning and using WPF as a line of business presentation platform.
In general, the comments I made above still hold... The design time support for WPF isn't here yet. If you're in a big rush to get a rich-client application out of the door, go with Windows Forms. Period. Microsoft aren't in any hurry to discontinue the GDI / Windows Forms platform, so you can count on good support for a fair time into the future.
WPF is not easy to master, but that shouldn't be where you leave your descision about whether or not to invest your time and energy into learning WPF. Despite its present lack of maturity, WPF is built around some useful, modern concepts.
In WPF, for example, your investment in well-written business objects with sound validating logic is a solid investment. Unlike Windows Forms, WPF's data binding is briming with features that allow interface controls to react to invalid user input without writing GUI code to detect those errors. This is valuable.
The styling and templating capabilities in WPF have proven to be valuable too. Despite the common misconception that the only use for styling and templating is to create on-screen eye-candy, the truth is that these features significantly simplify the coding of a user interface which gives rich feedback - like buttons that disable/enable themselves base on the state of the underlying business logic layer, or tooltips which intelligently find their text based on the state of the object under the cursor, etc.
These all add up to incredibly valuable features for "nothing fancy" business applications, simply because they make it easy to keep the interface congruent with the underlying data.
In a nutshell:
In Windows Forms you design your user
interface, then write code to drive
that user interface, which generally
also includes code to drive your
data objects.
In WPF you invest in the business layer that drives your data objects, then design an interface that listens to your data objects.
It's a seemingly subtle difference, but it makes a huge difference in your ability to re-use code... which begs the question: "Is the Windows Forms vs WPF question actually an investment decision?"
(This seems to have become my favourite thread.)
Are there any compelling reasons to use WPF
Absolutely! WPF is absolutely incredible! It will be a major benefit for practically any project because it has so many features and abilities that Windows Forms lacks.
For business applications the biggest wins will be:
The fantastic data binding and templating make the biggest difference. Once a decent data model is in place, it only takes a few clicks to create a data template and use Expression Blend to configure exactly how your object will look using drag-and-drop. And binding to things like color or shape is trivial.
Screen layout is incredibly flexible. Not only can everything in WPF smoothly adjust to container size and shape changes, but items can trivially be enlarged and rotated, and even extend outside their containing frame.
Ordinary objects can be presented any way you like, can easily have different presentations in different screens, can share presentation, and can adapt their presentation to changes in data values.
If you need to print, rendering to the printer is trivial. Properly configured, WPF makes Crystal Reports or SQL Server Reporting Services (SSRS) look like a child's toy.
Your user interface will look and feel much more dynamic, including nice features such as buttons that animate when you pass the mouse over them.
For utilities and games, other advantages come to the forefront:
You can easily add shapes, lines, and arbitrary drawings to your application without using an external editor. Every component of these can be data-bound and animated, or controlled by code. In Windows Forms you ususally just have to import a bitmap and use it as-is unless you want to go to a lot of work.,
Animations are cool! Users will be really impressed, as long as you don't overdo it. They can also help people see what is going on and reduce the need for hilighting. For example, when dragging an object you can animate the target to show what will happen if you drop it.
Colors, gradient fills, brushes, fancy fonts, rotation of any objects, tile brushes, etc. Anything you want graphically is yours for the asking.
Incredibly customizable. I needed to draw railroad tracks for one application, so I could drop a train on them. A couple of hours later I had railroad tracks I could draw anywhere on the screen using Bézier curves, and they would join and switch automatically.
The bottom line is that any significant-size GUI you could build in Windows Forms can be built in WPF in a third of the effort (or less) and look way, way better.
Does WPF require more resources (RAM in particular)
You do pay a price compared to Windows Forms, but it is a small one.
RAM can go up or down depending on your implementation. WPF stores its data more efficiently so individual objects are smaller, but there tend to be more objects in WPF than in Windows Forms so this balances out, and either one can come out ahead.
CPU will go up compared to Windows Forms. In my experience, the actual update of WPF objects onscreen takes about twice as much CPU as normal Windows Forms rendering. If your application spends most of its time updating the screen, WPF may not be for you. But in that case you're probably not using Windows Forms either: Most serious games are written directly to DirectX.
Disk usage will be slightly less for WPF because it takes so much less code than Windows Forms. The data will be the same size, of course.
One more note about CPU use: Animations and transforms (motion, translation, etc.) is actually more efficient on WPF than in Windows Forms because of its retained mode storage. It is the initial getting of the objects up there that is slower.
Maintenance overhead
WPF is a huge win over Windows Forms when it comes to maintenance. Since everything is done in 1/5 as much code as before, there is 1/5 as much to maintain. Plus all the boilerplate stuff is gone so you can focus on the code that actually does the work.
Benefits of XAML
XAML is the core of WPF. Although WPF can be used without XAML, XAML makes it incredibly easy to use. XAML has HTML's ability to easily specify a user interface, but its built-in tags are much more powerful, and you can easily define your own. (In fact, it is normal to do so).
Some specific advantages of XAML:
Your entire UI is defined in a text file that is easy to read and manipulate, both for users and tools
MarkupExtensions allow Bindings to be specified in a clear and simple way
Type converters allow properties with complex types to be easily specified. For example, you can say Brush="Green" or you can specify a radial gradient brush with three stops.
You can create your own elements
You can easily leverage WPF's powerful "attached properties"
Other insights
I dreamed of something like WPF for many years. Many people have implemented portions of this functionality, but to get it all in one place and at such a price ($0) is amazing.
WPF is a huge paradigm shift from Windows Forms and will take some getting used to, but the time spend learning it will pay itself back many-fold.
WPF still has a few warts even five years later, but its power will totally blow you away once you experience it. If someone tries to drag you back to Windows Forms, you'll only go kicking and screaming.
Tips:
- Do get a copy of Expression Blend for development
- Do edit XAML by hand occasionally
- Don't give up when it seems strange at first
WPF enables you to do some amazing things, and I LOVE it... but I always feel obligated to qualify my recommendations, whenever developers ask me whether I think they should be moving to the new technology.
Are your developers willing (preferrably, EAGER) to spend the time it takes to learn to use WPF effectively? I never would have thought to say this about MFC, or Windows Forms, or even unmanaged DirectX, but you probably do NOT want a team trying to "pick up" WPF over the course of a normal dev. cycle for a shipping product!
Do at least one or two of your developers have some design sensibilities, and do individuals with final design authority have a decent understanding of development issues, so you can leverage WPF capabilities to create something which is actually BETTER, instead of just more "colorful", featuring gratuitous animation?
Does some percentage of your target customer base run on integrated graphics chip sets that might not support the features you were planning -- or are they still running Windows 2000, which would eliminate them as customers altogether? Some people would also ask whether your customers actually CARE about enhanced visuals but, having lived through internal company "Our business customers don't care about colors and pictures" debates in the early '90s, I know that well-designed solutions from your competitors will MAKE them care, and the real question is whether the conditions are right, to enable you to offer something that will make them care NOW.
Does the project involve grounds-up development, at least for the presentation layer, to avoid the additional complexity of trying to hook into incompatible legacy scaffolding (Interop with Win Forms is NOT seamless)?
Can your manager accept (or be distracted from noticing) a significant DROP in developer productivity for four to six months?
This last issue is due to what I like to think of as the "FizzBin" nature of WPF, with ten different ways to implement any task, and no apparent reason to prefer one approach to another, and little guidance available to help you make a choice. Not only will the shortcomings of whatever choice you make become clear only much later in the project, but you are virtually guaranteed to have every developer on your project adopting a different approach, resulting in a major maintenance headache. Most frustrating of all are the inconsistencies that constantly trip you up, as you try to learn the framework.
You can find more in-depth WPF-related information in an entry on my blog:
http://missedmemo.com/blog/2008/09/13/WPFTheFizzBinAPI.aspx
WPF requires either Windows Vista or Windows XP SP2, which is not an onerous requirement, but it is a relevant one. If you want to run on Windows 2000 (which some people still do), then WPF won't work for you.
WPF is also a newer technology and not as proven as Windows Forms so you might choose Windows Forms as a less risky option, particularly for larger applications.
That being said, yes WPF is the future. Visual Studio 2010 is being rewritten in WPF, which will probably be the largest WPF application to date and it will also be a real test for the technology.
Obviously, legacy Windows Forms applications would be another situation where it is the correct choice.
As others have said, there are advantages and disadvantages either way you go here. The advantages of WPF, as others have said, include:
The ability to make very rich UIs relatively easily.
Easier animation and special effects
Inherent scalability (use the Windows Vista magnifier tool on a WPF application, and on a Windows Forms application: Note that in the WPF application, all the vector art scales beautifully)
(OPINION ALERT) I feel it's "easier" to do document-oriented systems in WPF
However, there are drawbacks to WPF, where Windows Forms comes out on top:
WPF's in-box control suite is far more limited than that of Windows Forms.
There's greater support in the third-party control space for Windows Forms. (That's changing, of course, but think about it: Windows Forms has been around since 2001; WPF just a few years. By advantage of time, Windows Forms has greater support in the community.)
Most developers already know Windows Forms; WPF provides a new learning curve
Finally, bear in mind that you can create great, attractive and engaging UIs in either tool, if you do the work (or use the right third-party tools). At the end of the day, neither is necessarily better in all circumstances. Use what feels right for the project.
The programming model for WPF is more open and flexible than Windows Forms is, but like ASP.NET MVC, it requires a little more discipline in terms of correctly implementing Model-View-ViewModel patterns.
My first LOB application with WPF ended up as an utter failuire, because it was a resource hog which brought my end-user's very-low-end laptops grinding to a halt... and this was ultimately because I just lept in with WPF + LINQ to SQL and expected a good result... and this is where WPF diverges so strongly from Windows Forms... In Windows Forms, you can get away with that sort of thing. WPF is much heavier on resources than Windows Forms, and if you don't architect your application to be lean, you end up with a 800-pound gorilla.
Don't shy away from WPF... explore it. But be aware that the acceptable sins of Windows Forms coding won't produce good results in WPF. They're fundamentally different engines, which lend themselves to fundamentally different coding patterns.
Last Word: If you do go ahead with WPF, get well acquianted with data virtualization for use with lists and grids. What is a simple data-bound ListItem or GridCell ends up being a hefty logical + visual object-graph in WPF, and if you don't learn how to virtualize, you application won't perform well on large data sets.
There is a very steep learning curve to WPF, and I recommend you get the obvious books first (Adam Nathan,
Sells/Griffiths, and
Chris Anderson) and
blogs (Josh Smith, etc.). Just be prepared for it, and make sure your project allows you the time to learn WPF.
In addition to learning the technology, spend some time learning the patterns used to construct WPF applications. Model View ViewModel (MVVM) seems to be the one that has gained a great deal of acceptance.
Personally, I think WPF is worth it but be forewarned. Also note that you effectively restrict your users to Windows XP SP2+ and Windows Vista. We've made that decision, but you may have some different requirements.
Both of technologies have their pros and cons. In a large application with a "classic" UI I'd use Windows Forms. In an application which require a rich user interface (skinning, animations, changing user interface) I'd choose WPF. Please check the article WPF vs. Windows Forms comparing WPF and Windows Forms.
Aside from the flexibility in UI design, there are some technical advantages to WPF:
1.) WPF doesn't rely on GDI objects. Well, I think it uses 2 GDI objects for the instance of the window itself, but that's practically nothing. I've been involved to a certain extent in a very large internal Windows Forms application. The people in our office sometimes run 3 or 4 instances of it simultaneously. The problem is that they frequently run into the 10,000 GDI object limit inherent to Windows 2000, XP and Vista. When that happens the entire OS becomes unresponsive and you'll start to see visual artifacts. The only way to clear it up is to close applications down.
2.) WPF utilizes the GPU. The ability for WPF to off-load some of the UI processing to the GPU is brilliant. I only expect this aspect of it to get better with time. As a former OpenGL programming hobbyist I can appreciate the power that comes from the GPU. I mean, my $100 video card has 112 cores running at 1.5 GHz each (and that's not top of the line by any means). That kind of parallel processing power can put any quad-core CPU to shame.
However, WPF is still pretty new. It won't run on Windows 2000. And in fact, a WPF application can be slow to start up after a fresh reboot. I talk about all of this on my blog:
http://blog.bucketsoft.com/2009/05/wpf-is-like-fat-super-hero.html
I think it is worth learning WPF. Once you are up to speed, design work on your forms is much easier IMHO. I wouldn't worry as much about the 'sexy' stuff. Most of this is just a fad. You can make 'normal' Winforms-style applications very quickly and easy in WPF.
The whole concept lends itself to easier design IMO.
I don't agree with some of the answers here. WPF is really well suited for line of business (LOB) applications. (The frog design LOB client is the best example). And besides all the possibilities to have your UI be eye candy (which is not necessary in business applications), WPF offers a lot more for you.
The data binding and templating features are just superior to Windows Forms. It also offers a far better way for separating code and presentation.
We've successfully used WPF for 2 LOB applications in teams with no more than 2-3 developers.
The biggest problem you will face is probably the steep learning curve of WPF (compared to Windows Forms) which will decrease development speed with developers not used to WPF.
We are currently rewriting our application in WPF from Windows Forms. Yes, there is a steep learning curve and you have to "re-learn" some things, but it is so worth it. And combined with WCF, we are finding we are writing less code, faster, and more robust than ever before.
Stick with it for a while, read Adam Nathan's book, and check out the ever growing library of third-party controls like those from Telerik and ComponentOne. One negative, in my view, is that the design tool, Expression Blend, is very awkward to use. The latest version is still in beta, but it just doesn't feel right to those of us who have used Visual Studio for years. Yes, it's mainly for designers, but some things you just can't do in Visual Studio.
Consider WPF if interface design is important to you, because WPF can deliver better UI experience. But Windows Forms has on its side the years of evolution, so it's proven to work and you can find many versed programmers for that platform.
Also portability may be an issue, WPF only works with Windows XP SP2 and up.
Also, WPF has a steep learning curve, meaning it's not easy to deliver a quality product without having specific WPF experience.
Well, one answer is "when you have to support 1.1 or 2.0", since WPF is part of .NET 3.0. There are known OS limitations for WPF, and there is an obvious skills issue: if you have a team of developers that know winforms, then it may be easier to turn out robust code with winforms. However, if you are writing a lot of UI code it is probably worth beginning to pick up WPF at some point.
WPF also shares a lot in common with Silverlight, so it has transferable benefits.
WPF comes with many advantages such as superb data binding features,
separation of concerns, separation of design and logic etc...
As a developer I enjoy the ability to define my UI using XAML as opposed to
being tied to the Windows Forms designer and I feel good knowing I can count
on another designer to make my app look good.
Personally I don't care older versions of Windows are not supported,
but one of the big problems with WPF is that is is not (currently/ever) supported
by Mono (http://www.mono-project.com) so WPF apps will not run on Mac OS or Linux.
(Altough Silverlight applications will).
If you have the time and resources to invest in learning WPF, do it!
Even if you're going to be writing Silverlight applications to support multiple OS's.
If you need desktop applications to run on multiple OS's stick with SWF.
There are many differences. We loved WPF for:
The declarative style of programming.
Animations and state transitions
Expression Blend is a great tool
Good style support.
However, we stuck with Windows Forms because:
The extra time it takes for a
developer to learn WPF when they
already know Windows Forms.
WPF will not run on Windows 2000 or
lower.
The biggest consideration when deciding which one to use is to consider what .NET Framework your target audience have installed. I find that more people have the lower .NET Framework versions that only support Windows Forms, but that's just my personal experience.
The advantages of WPF is that it is much easier to create nice looking GUI's with custom controls and animations. WPF also helps further serparate the presentation and logic layers. If you have designers, it allows you to farm of 95% of this work to non-coders and allows the coders to work on logic. The disadvantages are the software costs for Expressions Blend, and the lack of any of the Visual Studio code profiling tools working well as they tend to get caught up in the frameworks calls in trying to render XAML. I am sure there are others but these were the only two we really saw.
The main consideration is if you wish to require your customers to have to install .NET 3.0 or even better .NET 3.5 SP1. You will get some niegative feedback
WPF makes it much easier to hand off the forms design work to an actual designer, not a developer in designer's clothing. If that's something you'd like to do, WPF is your answer. If the classic Windows styled buttons are fine, then Windows Forms is probably the way to go.
(Multiple answers make the claim that you should use WPF if interface design is "important to you" but that's pretty vague. Interface design is always "important".)
If you have an MSDN license, check out Expression tools. It's designed explicitly for WPF, exports directly to Visual Studio and it may help ease your transition.
If you only care about supporting Windows and don't mind the time it takes to learn it, go with WPF. It's fast, flexible, easy to reskin, and has great tools to work with it.
As a side bonus, Silverlight is based on WPF and starting with either lets you gain the know how for working with the other. If things continue to go web based, having prior knowledge (and a library of existing code) to transfer easily to the browser (or Windows Live Mesh) might help give your software an extra lease of life.
If you decide to go with WPF, considering pros and cons already explained in the above answers, I highly recommend going through this dnrTV episode with Billy Hollis
In DotNetRocks episode 315, Brian Noyes discusses this extensively.
There is a known issue with text rendering in WPF. Many users report that the heavy use of anti-aliasing and pixel-blending used causes blurry text. This is a big deal breaker in some circumstances and, as far as I know, has been acknowledged by Microsoft at some level.
For the last 3 1/2 years I've been doing Windows Forms development (at two companies). Both applications were used extensively and ended up having GDI problems. Large Windows Forms applications will eventually run out of GDI resources - causing the end user to have to reboot.
Scott is complaining about Expression Blend and how it doesn't make sense to him as a developer. My first reaction to Expression Blend was like that. However, now I see it as an invaluable tool, but it really depends on what type of developer you are.
I am user interface developer that has had to perform the Integrator role, and I eventually found Expression Blend invaluable to create styles, and control templates in a WYSIWYG manner. I almost always have Expression Blend and Visual Studio up an running on the same project at the same time.
I also think that playing around in Expression Blend and taking a look at the XAML that gets spit out is an excellent way to learn the WPF API ... much like using the designer in Windows Forms and checking the C# code it spits out is helpful in learning how to use whatever you are designing there.
Expression Blend is helpful. Just give it a try, especially if you are working on the visuals for the application.
A quote from an earlier post from Mark:
In Windows Forms you design your user interface, then write code to drive that user interface, which generally also includes code to drive your data objects.
In WPF you invest in the business layer that drives your data objects, then design an interface that listens to your data objects.
I would argue that this is more of a design choice, rather than whether or not you are using Windows Forms or WPF. However, I can appreciate that certain technologies might be better suited for a particular approach.
Only if you don't have WPF expertise and you don't want to invest in it :)

Full-Time WPF Development

I am fortunate to be working for a company in which all of our new development efforts are all in WPF. Are there a lot of other developers out there in this situation? Are companies quickly adopting this as their primary UI platform? As developers we all see the value in it, but are companies buying into it?
I am doing WPF development at a major semi-conductor company. So far it has been a hit and miss experience. I was given pretty free reign to decide what development platform I used as long as we could support Windows Vista and later. Given that I had a pretty short development timeline for a rather large application and just two GUI developers to work on it, WPF seemed the right choice. HOwever as I got further along, some more warts of WPF manifested themselves... JUst look into "airspace" issues when integrating DirectX with .NET 3.0 implementation of WPF. Or look at the sorry state of the designer tools in Visual studio 2008. Still with these problems, they are relatively minor when compared to the development cost of creating a fully skinnable UI that supports RTL languages and animation. At one point someone (who worked at Microsoft no less) suggested that I look at SDL as an alternative to WPF. Yeah right.
Another problem that I have is that designers are still not doing uptake on the whole WPF/Blend tools. Most designers I know scoff at running anything other than Adobe tools on a Mac. It is up to us developers to translate their designs into workable code. I hate those turtlenecked d***ks.
Anyway, my company leaves the technology decisions to the people that are using it. So WPF was a natural choice given my requirements. I don't regret it but I wish it had been a bit more mature before they released it with Vista. There are some critical fixes that were put in .NET 3.5 that I need. HOwever, I don't want to force my users to download .NET 3.5 when .NET 3.0 is on their Vista system.
I think the major problem for the companies to adapt this new technology are
learning curve on XAML and new UI concepts
Developers have to forget all the knowledge they got on Winforms(or equivalent UI) technologies, most people are reluctant to give up their expertise.
The need for the new skill called "UX Integrators" who should be able to work with the new RIA tool called Expression Blend to style/integrate the design with the code.
The need for new Framework requirement(.NET3.5) and the new set of tools make companies or clients think twice before they take this route. They usually think that this may be a 'risky' path.
My company is concentrating mainly on the Microsoft RIA technologies like WPF and Silverlight. And we are helping other companies to bootstrap their WPF development efforts by creating Proof of concept/Prototype applications to show the power/easiness of WPF.
Our company is also doing most new development in WPF. It is working fairly well for us. However, it took 2-3 months for the organization to overcome the learning curve and to begin the "WPF Way of Thinking."
Similar to Louis' point, I think one of the reasons it is slow to take hold of the industry is that designers are hesitant to learn the Expression suite. Once there are an adequate number of Expression designers out there, I think companies will see more immediate benefit of using WPF.
One of the key benefits to WPF is the vector graphics. Because we develop apps that could be used on small laptops and rugged PCs, the ability of the UI to scale to different sizes of monitors is very beneficial.

What exactly is WPF?

I have seen lots of questions recently about WPF...
What is it?
What does it stand for?
How can I begin programming WPF?
WPF is a new technology that will supersede Windows Forms.
WPF stands for Windows Presentation Foundation
Here are some useful topics on SO:
What WPF books would you recommend
What real world WPF applications are out there
From my practice I can say that WPF is a truly amazing technology however it takes some time to get used to because it's totally different from the WinForms.
I would recommend you to take a look at this demo.
WPF is the next frontier with Windows UIs.
Built on top of DirectX, it opens up hardware acceleration support for
your .Net 3.0+ user-interfaces.
Emphasis on Vector Graphics - UIs scale and render better
Composable UIs. You could nest animated buttons in combo boxes.. the world's your oyster.
Is a rewrite with only minimal core components written in unmanaged code VS GDI-User Dll based Winforms approach which is a thin managed layer over largely unmanaged code.
Declarative approach to UI programming, User Interfaces are largely specified in a XML variant called XAML (eXtensible Application markup language) pronounced Zammel. This opens up WPF to designer folks who can specialized tools to craft UIs that the developers can then code up. No translation losses between wireframes to final product.
MS 'allegedly' will not provide any future updates to Winforms. Heavily invested in WPF as the way forward
Oh yeah, before I forget. Works best on Vista :)
You can get either Adam Nathan's WPF Unleashed Book or Chris Sells Programming WPF .. those seem to be the way to go. I just read the first chapter of Adam's (Lead for WPF at MS) book. Hence the WPF praise fountains :)
Take a look here http://windowsclient.net/ and here Windows Presentation Foundation (WPF)
Basically WPF is created to make windows form easier to design because of the use of XAML, designers can work on the design and programmers on the underlying code
WPF is the Windows Presentation Foundation. It is Microsoft's newest API for building applications with User Interfaces (UIs), working for both standalone and web-based applications.
Unsurprisingly, there is a very detailed but not all that helpful Windows Presentation Foundation page at Wikipedia.
The WPF Getting Started Page at the Microsoft MSDN site is probably a better place to start.
Is the new Windows Gui system. I don't believe its aim is to make development easier per se but more to address fundamental issues with WinForm, such as transparency and scaling, neither of which WinForm can effectively address. Furthermore it seeks to address the "one resolution only" paradigm of WinForm by mapping sizes to real-pixel sizes and making flow layout easier and more fundamental.
It's also based on an XML derivative making it easier to change the UI and forcing a separation of the UI and the core code (although technically you can still badly hack it together in this manner).
This separation also drives a desire to be able to divide the work into two camps, the designers taking charge of the XAML and layout and the programmers taking care of developing the objects used in the XAML.
Check out Eric Sink's Twelve days of WPF 3D.
Windows Presentation Foundation. It's basically Microsoft's latest attempt to make development easier, and provide a whole heap of nice functionality out of the box. I'm not sure where to start, but googling "WPF 101" should throw up a few useful links.
WPF is part of the .net 3.0 stack. Its microsoft's next generation Graphical User Interface system. All the information you need can be found on wikipedia and msdn's wpf site
To Get Started programming I guess check out the essential downloads on windows client

Resources