At patterns & practices we get the same questions from customers.
Sunday, I'm meeting with a HUGE company about implementing WPF in their new customer facing product they will start developing soon.
These scenarios are from Pete Brown:
· Cross browser, cross-platform, cross-device: HTML, JavaScript, etc.
· Rich media, forms-over-data business apps: Silverlight
· Deeper desktop integration and ISV apps: WPF
· Complete control and best performance: C++
Additionally, when I work with customers, I tell them about using WPF with ClickOnce if they are looking to minimize the impact of deployment.
I was at the TechReady Ask the Experts last week. I sat with Rob Relyea at the WPF table. The above guidance is what we told people who asked this same question.
Karl
I do the same kinds of recommendations, but I find that the hard part to draw the line on in a general guidance way is what constitutes “deeper desktop integration”. Also I don’t think “ISV” is a sufficient qualifier. I’ve worked on a number of ISV Silverlight apps that were perfectly targeted for Silverlight.
Josh
I should have also included this.
Start with (Don’t speak about technology until the below is defined. Technology can normally flow out of the below responses):
· What are the requirements of the application?
· What are the deployment requirements?
· What operating systems does the application need to run on?
· What devices does the application need to run on?
Karl
Now we are in lock step.
Would be nice to hear the official Microsoft definition of that though...
I think someone asked Pete for a definition of ISV, if I remember correctly it was basically shrinkwrapped software. If you are going to buy an application at Best Buy then that application would be written in WPF, not Silverlight.
Colin Blair
Josh Smith <flappl...@gmail.com> Sent by: wpf-di...@googlegroups.com 02/22/2011 06:21 AM PST Please respond to wpf-di...@googlegroups.com |
To |
"wpf-di...@googlegroups.com" <wpf-di...@googlegroups.com> |
cc |
||
bcc |
||
Subject |
Re: [WPF Disciples] WPF vNext |
There is a difference between shrink-wrapped, and built for sale to others. Many ISV’s I have worked with have to go in and do the install themselves and configure a bunch of things, but it is still software built for sale to others.
Sure. The term is fuzzy, but it’s about as good as you can get.
Why? Because the targeting of our products is itself fuzzy. We’re not going to say “Only X can use Y” when it comes to most developer products. Software development tools rarely have sharp lines delineating usage scenarios. We’ve all bent dev tools to our will, and when enough people do it, it becomes the new norm. That’s why we often say “in general” or are otherwise fuzzy in our answers: we don’t want to shut you out of avenues that may make sense in your own projects. The “in general” is where we primarily focus our own efforts, but it’s not the sum total of the capability or direction of the platform.
In general, though <g>, it’s companies like AutoDesk and similar who are big ISVs who tend to need the most out of the client platform. We take their feedback very seriously, just as we did with the community and non-ISV feedback in UserVoice. Requests from ISVs (and internal teams like Visual Studio), as well as large segments of the community, all help impact where we take the product.
As to information at the MVP Summit: Please ask us the hard questions. Please ask our execs the hard questions that will help you make the decisions you need to make. For the most part, our answers will be along these same lines. However, don’t let that stop you from asking for new opinions, or offering new scenarios. J
I’m looking forward to seeing many of you at the summit next week. Stop by and introduce yourself if we haven’t met in-person.
Pete
Pete Brown - Developer Division Community Program Manager - Windows Client
twitter: @pete_brown |blog/site: http://10rem.net
Silverlight 4 in Action – Now available!
WPF Dead? Silverlight Dead?
Here is the hard question I will be asking: Why are memory leaks in Silverlight 4 such a low priority for Microsoft? I cringe every time somebody comes on the WCF RIA Services forum waving an ANTS report trying to figure out where their memory is going.
cc |
|
bcc |
Subject |
RE: [WPF Disciples] WPF vNext |
[IMAGE] |
Josh Smith <flappl...@gmail.com> Sent by: wpf-di...@googlegroups.com 02/22/2011 06:21 AM PST Please respond to wpf-di...@googlegroups.com |
[IMAGE]
To |
[IMAGE] "wpf-di...@googlegroups.com" <wpf-di...@googlegroups.com> | |
[IMAGE]
cc |
[IMAGE] | |
[IMAGE]
bcc |
[IMAGE] | |
[IMAGE]
Subject |
[IMAGE] |
Re: [WPF Disciples] WPF vNext |
[IMAGE] | [IMAGE] |
>> now from customers about the future of WPF as the UX platform pushed by Microsoft.> Recent initiatives (for example > thewww.fixwpf.org<http://www.fixwpf.org%29>website) sow confusion in
Josh Smith
<flappl...@gmail.com> Sent by: wpf-di...@googlegroups.com 02/22/2011 06:21 AM PST
Please respond to wpf-di...@googlegroups.com |
cc |
|
bcc |
Subject
|
Re: [WPF Disciples] WPF vNext |
ISV is a legacy term.
Long-time ago, it used to mean shrink-wrapped software. (Roxio, Sonic, AutoDesk, SAS, etc.)
A few years ago, as shrink wrapped decreased, it evolved to include large scale software manufacturers (same as before but including Fidelity, Thomson Reuters, etc. )
So usually ISV == mid to large scale software vendor; it is for pro-developers who build software for a living and selling it in ‘traditional models’. We
differentiate from enterprise which means writing software mostly for in-house projects (not selling it).
I think when it comes to WPF guidance, we use the term ISV to highlight two things: we see that most adoption today was ISVs; we still see WPF having strengths that are appealing to them. In other words, they need features other platforms might not have today.
The guidance below is representative of current state of affairs with our client technologies:
1)
There are large scale ISVs who adopted WPF. Their investments are safe, Microsoft (among them) has bet heavily in WPF for Visual Studio, Windows Server,
and many other internal products. It is a great technology (still my favorite UX framework and architecture). Eventhough WPF and .NET has gotten great penetration, the technology is not cross-platform; this limits long-term strategic value (which is proportional
to investments).
2)
Silverlight is a great subset (and in a few areas) superset of WPF. Leverages the best design principles (e.g. XAML, property system, styles, templates,
etc. ).
The cross platform aspect (with phone, xbox, etc.) has strong/strategic value. If you are starting a new project and Silverlight has the features you want/need, you should use that; it is a safer set mostly because we have doubled down on the investments there
due to reuse on other platforms (and by that I don’t mean just Mac, phone and the other platforms are more important).
3)
All that said, with both WPF and Silverlight we do see areas where ubermost performance or deep integration with OS is needed; in the end Windows
is still written in C++ and therefore all platforms should have a way to integrate C++ to bring in the deepest Windows integration. This is an advanced need, not for every app, but a good escape valve when needed. At same time you can see in the industry
that C++ is coming back. iphone and Mac developers are writing complex algorithms in C++ (they might write UI in cocoa, but when they get to lower-level intellectual property, it tends to be C++) so again the technology is at play as a cross-platform reuse
strategy.
4) HTML5 is the new kid on the block. This is simply what customers are asking for. Last year, we had the incident where an executive said “our strategy on cross-platform changed” .. I think this was misstated as “our customer’s strategies have evolved. We used to think Silverlight (on Mac, Windows, and phone) would be enough. We of course now hear that iOS, Android, and similar OSes do matter to customers, so we leverage the common denominator: HTML5”. Yes, a growing standard, but with time, it will play a role.
None of the above should be news to you. This is just current state of affairs. The key at Microsoft is we love developers and must embrace and provide great choice. If embracing HTML is it, we will provide that as yet another choice. The other technologies
will continue to evolve and there will be new ones that hopefully improve on what we have today. Also, note that these are just options (not mutually exclusive choices). We will continue to have multiple options because our customer’s needs are so broad.
I think with regards to guidance, the answer is simple:
If starting a new project, you should use the technology that helps your current and long-term needs aligned with the long-term investments expected.
1) HTML -- if you can do it with the technology and you believe it is far enough along with regards to standards/stability. IE9 is a great step there.
2) Silverlight -- when HTML can’t do, SL is next. Assuming the platforms you want/need are served by them.
3) WPF is still a superset of Silverlight; a few scenarios will only be met by it. It this is the best/only choice, it is OK.
With any of the above, you can use C++ as your escape valve to get performance and integration –when needed--.
If you already have a project, then you should continue your investment if it is meeting your needs. Understand the roadmap and figure out whether migration will ever be at play; if it does not, no worries, we are committed to all of the above; just have realistic expectations on how quickly and how far these evolve.
Please know the above is just me pointing out the obvious and it is just my personal opinion. I am sure Microsoft will share their road-map when they are ready.
Microsoft is not hiding anything or being vague about it on purpose, data is still being gathered for us to create better guidance and roadmap.
1) We have the challenge of predicting when technologies fully converge (WPF and SL). This is in the works, and this will dictate roadmap more than anything else. We can’t leave people hanging with no cover.
2) We are listening to customers; our ISVs and customers are incredibly important. We have to listen to what they want and balance that to what is realistic. Again, realistic is critical here.
Again, huge emphasis on personal, that is how I see it. Apologies if all I pointed is obvious and it disappoints on it being a crisp roadmap. I will be at the summit this week if you need to chat (but honestly there is not much else to share than that)
From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com]
On Behalf Of Eric Burke
Sent: Tuesday, February 22, 2011 6:26 PM
To: wpf-di...@googlegroups.com
Subject: Re: [WPF Disciples] WPF vNext
+1
(Similarly) When I worked at SGI, "ISV" meant "someone who writes software for our hardware platform that isn't us".
From: Charles Petzold <c...@charlespetzold.com>
To: wpf-di...@googlegroups.com
Sent: Tuesday, February 22, 2011 10:27 AM
Subject: Re: [WPF Disciples] WPF vNext
I always understood Microsoft’s use of the term “ISV” to mean “Anyone who creates and markets commercial software who is not Microsoft.”
Charles
Sent: Tuesday, February 22, 2011 9:58 AM
Subject: Re: [WPF Disciples] WPF vNext
I think someone asked Pete for a definition of ISV, if I remember correctly it was basically shrinkwrapped software. If you are going to buy an application at Best Buy then that application would be written in WPF, not Silverlight.
Colin Blair
Josh Smith <flappl...@gmail.com> |
02/22/2011 06:21 AM PST Please respond to wpf-di...@googlegroups.com |
To |
||
cc |
|
|
bcc |
|
Subject |
|
|
|
Hey Jer,
I am not trying to spin your words, so correct me if I am misinterpreting that we are in agreement in principle (even if our wording is sounding like we are not).
1) We agree that the term “dead” is useless and it means too little. We also agree that no technology at Microsoft dies quickly and that is not a concern. WPF is not dead, everyone is safe.
2) We agree that cross-platform today has a different meaning than it did 4 years ago when we began Silverlight. As we started, Mac OSX and Windows was a reasonable goal.
Today, there is iOS, Android, webOS,etc. I don’t think the owners of these OSes will let us ship our run-times in their platform – we can have an academic
discussion around Android –but that won’t get us iOS, BlackBerry, webOs, and everything that comes later. Again, Bob did mean what he said, but in my opinion what he did was word it wrong, he said “we shifted” and the meta point to me was “our customers
are asking us to shift”. We have to listen to customers, else we go out of business. Another meta-point with Bob is his message sounded like an “or” decision, and it was an “and”. We continue to invest into Silverlight, and we are adding HTML. Nobody
in the Silverlight team has moved to IE team; we doubled down on both. BTW, SL and WPF is same team now-a-days (so when you hear me say SL, that is both).
3) You are asking us to listen to our customers. We agree there and that is exactly what we are doing. Please keep in mind, you are not the only customer – even if you are my favorite one J-.
I think we agree on all of the above, right?
I do see a disconnect on expectations, and I think it is mostly based on context. The below is a hypothetical argument for you Jer. The estimates that I am
sharing are not real, I am not in engineering, but they are not far from reality.
You are telling us to improve perf in WPF. We hear this loudly and we are trying to figure how to solve it. Unfortunately, there are a few pieces to consider:
1) First of all, a lot of our customers are telling us to invest more into Silverlight. Let’s say (again made up) that demand is 4-to 1. How do we justify a revamp of the graphics architecture in WPF. This is not trivial work; the expertise in this space is limited, we can’t clone our folks to 5x to meet everyone’s needs.
2) Let’s assume we did take on the work. My guess (again, I am not engineering) is that it would take two years to implement and thorougly test a release. At the stage that WPF is at, a rearchitecture or huge changes on the graphics stack would be 80% about testing and 20% about the dev work. It is not a trivial amount of work. Would we get the performance you want across myriad of devices? We don’t know. WPF bet on hardware, and there is new devices out there that are trading hardware for battery, weight, or simply for cost. it would suck to do that much work, make you wait a long time, and then not get there. Let’s get real on the asks; you say “improve perf” but you are asking us to do a “significant re-write”; these two asks are different.
3) By the time we get there, what will be a more powerful framework? Silverlight, WPF, C++, or SuperNew.Next ?? we don’t know today. We go back to #1 and look at demand We are in agreement that “customers” is the driving principle.
The WPF has looked at the trade-offs, and risk many times. We are also looking at what customers need. Jer, to you it is all about graphics. To many others, it is about data. So, how do we serve all customers??
The strategy is exactly what you have seen/heard:
1) WPF 4.5 is going to have some significant data binding performance improvements.
2)
We are not redoing the graphics framework, but we are doing a lot of work to let you interoperate with lower level graphics so that if you need more
graphics perf you can get it, and still keep the RAD of the rest of the framework.
If you ask me, this is the better compromise they could have made. {there are other improvements, I am just pointing out the ones that I think you care about}
Your last statement refers to a plugin, I assume you refer to Silverlight. Today, Silverlight is much more than a plugin. It is the run-time on phones. It runs out of browser on Windows. It has a place in other platforms; unfortunately I don’t think it will be on all platforms (and that part is beyond Microsoft’s control, not that I am saying we would do it on all platforms, we can’t target everything), that is why HTML.
If you are coming to summit, or you want to meet while at MIX – let’s chat then. It is not that I want to quiet the thread; it is simply that we can argue forever and still not reach agreement because we are looking at different sets of data and demands. If you have a silverbullet that solves our problems, we would want to hear it. In the mean-time, please keep in mind all of the above (and many other factors that are often missed).
Anyone with concerns, you are always welcome to email me directly. [I am guilty of not reading this alias as often as I could, this week I am on it cause of the dinner Karl mentioned], but never hesitate to go direct or call.
We are always eager to listen to you (and rest assured that others, in particular Rob, who owns WPF are crawling through the internet for the feedback, this gets discussed a lot internally).
Hope it helps; apologies if it does not, and again, wait for Rob Relyea or someone else to make it official. That is just my 2c as a person who bet heavily on WPF but has seen the data that drives the trade-offs the team has to make.
MVP != “Always agrees with Microsoft” J
One of the two CAD (Client App Dev) MVPs of the year is the one who posted the list of problems with WPF. When I eval the CAD MVP candidates, I look for people who are doing right by the community and are helping to advance the technology and the overall community’s success with it.
Pete
Pete Brown - Developer Division Community Program Manager - Windows Client
twitter: @pete_brown |blog/site: http://10rem.net
Silverlight 4 in Action – Now available!