Answers and thoughts about the Windows 8 Metro style Applications

I just come back from 2 days of MS tech days in Paris, and I would like to publish what I've heard & understood related to the Windows 8 / WinRT topic.

In fact, nothing is really new since the latest "build" conference in California, since it seems that the MS guys in France are STRICTLY TIGHT to respect the drastical and confidential planning imposed by Steven Sinofsky (head of Windows team).

Anyway, here is a recap of the previous episodes, and some answers to questions related.

Previously on Windows

WPF was proposing developers to reinvent the UI application experience with the power of declarative programming (the advent of XAML), rich composition, customization and GPU boost. At the end of the day, it’s a fact that very few developers have leveraged this option. Indeed, most of us continued to build old-fashion-style-full-of-data-grids applications requested by our users (or what we thought) with this technology that wasn’t fit for that (don’t even get me started with WPF DataGrids performances ;-)

Now what?

With the new Windows 8 to come, developers may be able to develop two different types of applications: Metro style Apps, and Desktop Apps.

• Desktop Apps are the classical ones (.NET, Silverlight, Win32 or web 2.0 ones), fortunately still supported by Windows 8.
• Metro style Apps are the new way of doing applications for Windows 8. This new way relies on a methodology and on the new windows Runtime (a.k.a. WinRT). We can summarize the “Metro” style in 4 recommendations:

1. Provide a full screen experience tailored to your users’ needs: no more chromed frames around your app since the technical plumbing should be definitively hidden
2. Align your content within the screen: it’s clearer for humans
3. Don’t use 50 different colors or {font|image} sizes within your application. The size of the elements should be used to drive the user's focus accordingly
4. The user experience SHOULD BE fast and fluid. The widgets should always dynamically but subtly inform us that something is going to happen, and every code-behind that take more than 15 milliseconds should be executed asynchronously

Whereas WPF came with recommendations only, the new “Metro” style application for Windows 8 aims now to regulate developers more strictly. The idea here is to force them to fall into the pit of success (Windows team version ;-)  Without other choices (in the case you want to leverage on the new windows runtime WinRT, instead of continuing to build classical Desktop Apps).

Looking at the Metro Apps demos, I had the feeling that the pit of success won't be easy to reach, even with more control achieved by the development ecosystem (whether at build or run time). Indeed, a lame interpretation of the metro style may be an application with tons of pages to slide (it'll worth to have a touch device in that case ;-).

I definitively think that the adoption of the Metro style guidelines and constraints won't save us to rely on real ergonomy specialists & BAs in order to provide relevant tailored experiences for our users (message for IT managers ;-).

Q&A

Is every Metro style Applications forced to be released on the MS market place? Even my enterprise private applications?

Yes ;-( as it is done with the Apple Store. It may change, but there is today only one public store to release Metro style applications.

It took me time to learn the WPF way (XAML, M-V-VM pattern, etc). Is all my knowledge lost?

Nope. If you look at the Windows 8 Platform and Tools diagram below, you can see that XAML is still the declarative language for UI (whether you develop your code behind in C++, C# or VB.NET). WinRT aims to provide a better and more performant XAML based engine for our UIs.

I heard that HTML5 was the first-citizen language for building Metro style applications. Is it correct?

Nope. It is a fact that HTML5 (with JavaScript as Code behind language) makes the buzz and is currently mostly implemented today. But MS claims during those tech days 2012 that WinRT will be fair and provide the same capabilities to the 3 existing citizens: XAML-C++, XAML-C# and HTML5-Javascript. In fact, all WinRT APIs are natives and according to the MS guys, WinRT is like a “modern COM”.

Is .NET dead?

Nope. .NET will be still supported by Windows 8 for Desktop Apps or Server Apps. And if you decided to build Metro style applications, you will still be able to develop them in C# (instead of HTML5 or C++). In fact, you’d rather use C# as language for your Metro style applications if you want to ease the “every code-behind that take more than 15 milliseconds should be executed asynchronously” recommendation via the amazing async-await C# language extension (not available in C++).

For the record, the .NET framework is partially loaded when running a Metro style application developed in C#. I said partially, since some APIs are filtered/prohibited within a Metro style context. Whether at build or run time (e.g. no MessageBox is allowed for instance; the compilers will raise errors if you try, whether in C# or C++).

Anyway, I'm looking forward to see the next Windows 8 user preview (end of February).

About WinRT and .NET in Windows 8

A very informative post of Sasha Goldshtein here.

As a bonus here: a diagram of the Windows 8 platform layers per application type.

Has Microsoft initiated its own Nokia-ization?

Some MS officials, by recently saying that Windows 8 apps will be created in HTML5 and JavaScript and by deciding not to mention anything about .NET and Silverlight have fostered speculation and have introduced some confusion and chaos (see here, here, but mostly here).

Here is my thought about this Jupiter/windows 8 buzz/fiasco:

1. XAML is not dead: even if the future of WPF seems highly compromised by the advent of Jupiter & windows 8, I think that the pattern of its declarative langage is not dead. The Windows team and their IE peers certainly want to kill Silverlight or WPF for different reasons, but Jupiter seems more like a "Next Generation" XAML-based framework, than a uniquely dedicated and optimized for HTML 5/Javascript UI platform. In that context, I found also very interesting to notice that the XAML team has recently joined the Windows one.
2. .NET is not dead either: While it seems now realistic that the Windows 8 team will provide an alternative to WPF or Silverlight (with the help of their IE classmates, and surfing on the HTML5 wave), I don't buy the option where the Windows team may be confident enough to initiate the dismantling of the .NET platform (I wish them good luck if they want to offer an alternative to the entire .NET ecosystem built ​since 2002 ;-)
3. But it's really time to adopt an SOA model for our desktop applications: The volatility of MS UI technologies is so important than we definitively have to avoid from putting all eggs in one (fragile) basket. Here is my advice for desktop applications: wherever it is possible, avoid from embedding business layers whithin them and limit them to consume services instead (whether web/WCF, or through a MOM). The responsibility of our rich desktop applications should only to provide the information in a nice, efficient and ergonomic way (which is all but simple). Note that I'm not talking about web app here (maybe within another post?).
4. It seems now wise to wait the "Build Conference" in September, in order to have concrete and reliable information on this subject (and not rumors or blog noises)

Anyway, the future don't looks bright for MS with its internal wars/clans (Windows team vs Dev team) and the lack of legibility of its strategy (Silverlight? WPF?).

Microsoft sorely lacking a leader able to provide a vision and to bring every team into line. They definitively need a leader. Moreover, they probably need a designer at the head of their organization. Someone that will try to change people's lifes -whether for good or bad reasons-like Steve Jobs with Apple.

Otherwise it could be the beginnings of a (long) Nokia-ization for the Redmond giant...What a pity!