Note: this post is about marketing to developers (not general public).
Yesterday Tim Heuer published a blog post titled “Top issues for Silverlight” where he summarizes reported Silverlight issues. Apparently number one issue is “WPF and Silverlight feature (dis)parity”. Tim writes:
It’s a little weird to call this one an issue with Silverlight, but this was seen requested more often in these areas that it is worth calling attention to. Some of the genesis of this angst comes from an expectation that WPF applications ‘just work’ in Silverlight and not understanding the areas of the subset in both XAML and the .NET base class libraries (BCL).
Now this is true but one has to wonder where this expectation comes from.
Silverlight is NOT a subset of WPF
The root of this problem (at least how I see it) is the initial marketing message of Silverlight for developers was that it is a subset of WPF. Now Microsoft is a serious and cautious company and you would hardly find any direct evidence of this but this is what gets stuck in minds of developers who know about WPF and/or Silverlight from various presentations before they dig deeply into development.
It’s hard for Microsoft insider to realize this. That is not that obvious even for someone who is working with both WPF and Silverlight. But if you take someone who does some real work with either WPF or Silverlight but not both and ask them what’s the relation between WPF and Silverlight, most of the time you are going to hear the mantra – “Silverlight is a subset of WPF”. I’ve heard developers, project managers, etc. with no experience in WPF and/or Silverlight repeat this numerous times. And that was exactly as I saw things before I started coding with both. This is encrusted deeply in the minds of developers and is the main source of frustration when they realize that this is not exactly the case.
I guess with all the advances in Silverlight over the recent years this disparity became a little more expected than before but the “subset” idea is pretty much still alive. Now I don’t know what needs to be done to kill this mantra and I’m not even sure Microsoft’s business departments want to kill it but I think this is the main source of this “issue” being number one.
Silverlight for Windows Phone 7 is NOT Silverlight
This subtitle is a little too drastic on my part but I’ll explain what I mean in the next few paragraphs.
One might think that WPF vs. Silverlight case was one of it’s kind but just this spring during MIX10 conference while unveiling Silverlight as one of the main developer platforms for Windows Phone 7 Scott Guthrie said this: “It’s not Silverlight Lite. It’s not Silverlight Mobile. It’s Silverlight.” (watch MIX10 Day 1 Keynote).
Now the wording is really clever. And later he explained that it’s Silverlight 3 with some parts of Silverlight 4 and phone specific stuff. He never said that you can run exactly the same code on the phone as you can on desktops and those who were interested in WP7 development understood that. But majority of the folks who just listened to this as high level overview have this notion stuck deeply in their minds. They believe that they can continue working on their Silverlight apps as they did before and then if they decide to move the app to WP7 they will only have to shuffle the UI a little to fit the smaller screen.
Do you think they are going to be frustrated when they find out that this is not the case? What do you think is going to be the top issue for Silverlight for Windows Phone 7? My guess is “Silverlight and Silverlight for WP7 (dis)parity”.