|How Microsoft Could Have Done Metro|
|Written by Mike James|
|Friday, 13 April 2012|
Much has been written about the moves that Microsoft is making to turn Windows into an operating system that can work on tablets as well as desktops. There seems to be a clear split into the programmers who have too much to lose to even consider that the new might replace the old, and those who are simply fascinated watching the slow-motion train wreck.
Currently Microsoft is still playing things carefully and trying not to give definitive answers to difficult questions like:
In fact I guess the big question is:
You may still be of the opinion that even asking these questions is just stirring the murky waters and hoping that something interesting will float to the surface. However, the fact that the waters are murky is all down to Microsoft and what is more there really wasn't any need for any of it.
Consider for a moment an obvious alternative to the current path that Windows 8 is on. It is such an obvious alternative that it is difficult to see why it isn't more discussed.
So you are a big company and you have a successful desktop operating system which has .NET as its core cutting-edge technology. You also have a mobile phone, WP7, which is based on a Silverlight development environment. You aren't having much luck with WP7, but the development environment is almost certainly the easiest to use of all the mobile phones.
Now you need a tablet operating system. Forget the fact that you have had a tablet operating system in the past, you need something new that can go up against iOS and Android.
What is it you need exactly? Something that looks good, distinguishes itself from the rest and is suitable for running on the reduced hardware in a tablet.
You already have a mobile phone operating system and development environment and mobile phones don't have much in the way of hardware power, even if they are getting more powerful every month.
In this position, surely what makes sense is to use the Silverlight development environment that you already have to implement a tablet solution. You can still have a Metro style interface - the UI is just so much window, oh OK, Windows dressing. WP7 is already a Metro interface.
Let's consider the advantages of going this route rather than the COM/C++ based WinRT:
The first is that .NET programmers would have felt that the technology that they had been working with for so long was still central to Microsoft. It would also have allowed Silverlight programmers to run their creations on WP7 and the new tablet OS or the tablet OS front-end to desktop Windows. And it would have meant that instead of telling developers, "you can still use XAML and that's a lot like Silverlight" they could simply have continued to use Silverlight.
On the way, the existing XNA infrastructure could have been allowed to work in the same way. If Silverlight programmer are feeling a bit left out of it all pity the poor XNA programmer who really have no where to go. XNA may not have been perfect, but it was the only relatively easy to use 2D/3D graphics facility available under Windows.
The alternative strategy would also have avoided the small problem of moving Window Phone 8 to supporting WinRT/Metro apps.
This is another area where Microsoft isn't giving much away. It has stated that all existing WP7 apps will run on WP8 - and then it all went quiet. It is clear that Microsoft has two choices, neither of which is particularly attractive from a PR point of view:
The idea that the next version of Windows Phone isn't going to support WinRT/Metro apps is ridiculous. What company in its right mind would split off tablets from mobile phones in this way?
So what does Microsoft gain from dumping Silverlight as a potential tablet development environment?
That is a very good question and the cruel answer is - a slow train wreck.
What Microsoft claims to be gaining is speed and efficiency. You need both to run on a tablet, and even more so to run on a mobile phone, which brings us back to the fact that the Silverlight-based apps on WP7 seem to work OK.
Even if you make the argument that to go up against iOS you need something even faster, you could use the same huge engineering effort going into WinRT/Metro to making the Silverlight environment go faster. You could add a native code mode for those times when nothing else would do - a much more reasoned and measured response than making the whole thing native code.
At the end of the day, you have to ask what technical imperative made Microsoft choose to implement a whole new way of doing things, rather than simply migrate some existing stuff. Silverlight would have been a great front-end to Microsoft's tablet offering, just as it makes a great front-end to its mobile phone. It would have brought unity and not division and no technologies would have had to die in the making of this new system.
Now imagine you have to sell to the developer world the Silverlight- based version of Windows 8/Metro. You could say it was the easiest environment to create apps in and, what is more, you don't have to learn anything new. And there would have been no need to manage the negative PR.
Given there seems to be no compelling technical reason to make the choice that has been made, you either have to conclude that Microsoft is afflicted by a corporate madness or there are some deep political reasons motivating the behavior.
or email your comment to: firstname.lastname@example.org
|Last Updated ( Friday, 13 April 2012 )|