When Should You Use Metro, Version 2

During my busy week at the Microsoft BUILD conference, I cranked-out a quick and rough decision tree designed to help you decide which Microsoft platform you should use for app development: Silverlight/WPF, HTML5, or the new Metro/WinRT. The chart proved to be very popular, so I thought I'd revisit the decision tree and with the benefit of more time to reflect, produce a new, more complete version.

Thus, I present version 2 of the "How to Pick Your Platform" chart.

What's Different?

In the original chart, the first question I made you answer was, "Do you need to support Windows 7?" It's a fair place to start given that everything new introduced at BUILD is Windows 8 only. There is no path for Metro back to Windows 7 (or Vista and XP, for that matter).

But in today's world, Windows is not the only relevant OS in town. We've been trained through years of Windows dominance to think building for Windows is building for the biggest audience, but we need to update our thinking.

Yes, Windows remains the dominant desktop OS. The problem is that many people are now doing more "computing" on non-desktop devices, like iPhones, iPads, Android devices, and (for now) Blackberry. In this realm, Microsoft (and Windows) is just one OS choice among the pack.

So the first question shouldn't be about which version of Windows you want to support, it should be about your desire to build software that targets the broad marketplace of devices and operating systems.

With that change, if you answer out-of-the-gate that you want to build an app that can reach iOS, Android, and Windows, the decision is easy. Use HTML5 and JavaScript for your frontend (perhaps using PhoneGap to leverage more native device features), and any server technology you prefer for your backend (including ASP.NET). (This is the type of app scenario perfectly served by the JavaScript/HTML5 Kendo UI framework.)

Silverlight, WPF, and WinForms

In the first version of the chart, I oversimplified the choice of Silverlight/WPF if you decided to build Windows apps that support all versions of Windows. I've expanded that decision tree in version 2.

As part of that expansion, I also reintroduced WinForms as valid platform choice (because it is).

I was reminded during the BUILD week after visiting with a customer that WinForms is still hugely active as a Windows development platform. Of course, I knew that from Telerik's own experience with growing WinForms popularity, but it doesn't get talked about often enough. We've all be talking XAML for the last 3 or 4 years, but WinForms has continued to get work done. It was good enough to solve business problems in 2001. It still remains good enough to solve many business problems in 2011.

So while Microsoft is spending time with Windows 8 trying to win the minds of consumers, the business app story marches on with Silverlight, WPF, and WinForms. Pick between these platforms the way you always have and the apps will work Windows 8 through Windows XP.

The only new "edge" for Silverlight is that your skills building those apps will more quickly translate to Metro if you decide to build Metro apps in the future.

Metro App Types

Another "enhanced" decision point in the chart is around deciding if your app belongs in Metro or in the "standard" Windows desktop mode (assuming you're already targeting Win8). With the support of a great new blog post from Telerik EVP Doug Seven, you can now decide if your app fits one of the five Metro app scenarios:

• Data Snacks
• Social Networks/Mash-ups
• Content/Media Apps
• Casual Games
• Graphical Games

Metro in Windows 8 is not appropriate for every app.

Clearly, missing from Doug's classification are any business app scenarios. This is intentional. Business apps still belong in desktop Windows, even with Windows 8. And if you start building for the desktop, the platform decision is back to Silverlight, WPF, and WinForms.

Three Flavors of Metro

Finally, assuming you answer all of the questions correctly to lead you towards building Windows 8 Metro experiences, I expanded on the process of selecting the proper "flavor" of Metro. Generally speaking, there are three flavors of Metro, all underpinned by Windows Runtime (WinRT):

1. XAML + C#/VB WinRT
2. HTML + JavaScript WinRT
3. DirectX + Native Code WinRT

You can theoretically use any of these options for building any Metro app, but realistically, some are better suited for certain tasks than others.

Most obvious, native code and DirectX. I guess you could build a Twitter app with Native Code, but why would you? You'll waste way more time coding than you'll gain in performance, so probably not the best choice. Instead, this raw, on the metal option is generally best reserved for rich, immersive games.

After that, it becomes more a matter of choice.

Blend 5 and Visual Studio vNext provide similar design and debugging experiences for .NET and JavaScript, so at some level it comes down to your preferred language and team skills. Microsoft is writing many of the built-in Metro apps with HTML/JS (like the Windows Store and Metro Mail), but my guess is that the community at-large will do lots of Metro development with XAML.

Don't Get Overwhelmed

Choice is good to a point. Too much choice is paralyzing.

With the introduction of three new ways to build apps for Windows, you may feel like you're trying to pick between a billion new and "old" ways to build for Windows. Don't panic. Just use my simple chart, and your decision is easy. And no matter which decision you make, Telerik will continue to make you a .NET Ninja Rockstar with industry leading tools and support.