Windows 8, Metro, HTML & Silverlight: some questions answered.
Windows 8 is here!
Well, it’s been announced 🙂 The last few days, a lot of new information has been released about Windows 8, specifically aimed at the new Metro-style apps. Windows 8 will essentially feature 2 modes: the regular desktop, and the touch-optimized Metro style. I’m not going to go into much detail about this: I’m guessing people who end up reading this post already know a thing or two about Windows 8. But: I’ve been getting a lot of questions on this topic, so I decided to try and answer a few, and share my 2 cents.
Some things we’ve been hearing: Windows 8 changes everything. HTML5 + javascript is the way to go. XAML is a first class citizen. OH MY GOD IE10 Metro doesn’t support plug-ins: Silverlight is dead. Silverlight is alive and well. Et cetera, you know the drill.
Time to take a step back. Does this really change everything? Is the change that big? Well: I don’t think so.
What is Metro? What about the regular desktop?
If you look at Windows 8, it actually falls apart in 2 vastly different experiences. We’ve got the regular desktop, which is much like Windows 7. Everything we know about Windows 7 still applies to Windows 8: all the applications we’ve built, including WPF, Silverlight, in-browser apps built with ASP .NET MVC, … Winforms, even, still run on Windows 8. Aka: the .NET we know and love. This is the way applications will be built for a long, long time: just as we do it now.
And then there’s the big new thing: Metro-style apps. This is what all the fuzz is about.
One way to look at this, and this is the way I like to look at it, is: in fact, Metro style Windows = iOS or Android, the Microsoft way. It’s made for tablets/slates, it’s made to be touch-optimized. It’s aimed, mainly, at consumers, or at apps that don’t require a lot of input. And every app you build for it will be built using the new development paradigm: WinRT, in combination with HTML/js or XAML/C# (I know, VB .NET etc is also possible – but let’s just assume the majority uses C#), and they will be distributed through the Windows App store.
WinRT (regardless of how you talk to it – through JavaScript or C#) allows us to talk to device-specific functionality through C# or js (although it does still run in its own sandbox). That’s “The Cool Thing”. But in essence, writing Metro-style apps is a lot like writing apps for Android or iOS: you’ve got the power to use most of the capabilities of the device, the distribution mechanism is more or less the same, and the apps are OS-specific.
But at the same time: Metro style apps do not run on anything but Windows 8 – Metro style (nope, not even the regular desktop). Metro apps do not run in a browser, do not run on other devices, do not run … well, you catch my drift. Even though you code these apps using syntax that is much like the XAML/JavaScript you’re used to, they are not redistributable through other channels.
So what have we got here? A new type of apps, with lots of capabilities, built in a new way that’s a lot like what we’re used to, but not quite the same.
What about IE10?
A nice example of this is IE10: there will be 2 versions of this: a regular IE10 for the desktop, and a Metro Style IE10. This is actually just a Metro Style app: that version will not run on anything else but the Metro Style desktop. By the way, this also means that other browsers like Chrome, Firefox, … do not run in Metro Style mode – unless Google & Mozilla create Metro-versions of their browsers, and Microsoft allows it. Just like none of your existing apps run in Metro Style mode (you might start to see why I like to think of this as “MS’s iOS” :-)).
Now, of course: web applications do work, as you’re just browsing to them using IE10, Metro Style. But don’t be mistaken: these are the web apps we’re used to, and they are confined to the browser sandbox, just as we’re used to. They do not have access to any of the WinRT-stuff. It’s, well, just a browser.
And what’s more: it’s a browser that does not support plugins. None.
Well, that sucks. Shouldn’t these plugins be supported?
No plugins. That means: no Flash. No Silverlight. But also: no Adobe Reader, and none of the other plugins a lot of LOB applications rely on.
There’s been a lot of concern about this: does this mean Silverlight is dead? Or Flash? Isn’t this a very bad decision?
No: it’s a good decision.
It’s like wanting to have support for Flash or Silverlight, in-browser, on your smarthphone or iPad. It can be done, technically (there’s a Flash for Android), but it will offer sub-par user experience, almost by definition. Steve Jobs was right on this one: if you create a Flash app (or Silverlight app for that matter) that runs in the browser, it’s supposed to be manipulated with keyboard & mouse. Using an app designed for those input types on a touch-based device is not – and I mean: never – a good user experience. Let alone the different amount of screen estate, orientation, … any designer will tell you a specific form factor with a specific input type requires an application design catered to those specifics.
From an end-user POV, not supporting plugins in Metro is a good thing. And for those who are concerned about Flash or Silverlight: this is, and stays, fully supported in regular Windows 8. Remember: Metro apps are touch-centric apps, for slates and tablets.
Touch centric? Metro? Isn’t this supposed to work with mouse & keyboard as well?
Yes, it works. But this is one of the things where I’m quite opposed to what Microsoft is trying to sell us with its Metro paradigm: the idea that Metro works just as good with mouse & keyboard.
With Metro, we’re looking at a UI and UX tailored to touch devices. As any – and I mean any – UX specialist will tell you (and as I’ve stated above): a different input methodology requires a different UI approach to ensure good UX. Even Microsoft themselves tell us that: just read their Metro design guidelines for WP7: it’s based upon the notion that a touch-centric UI is vastly different from one in which you manipulate your apps with mouse and keyboard. So, Metro with mouse and keyboard? It’s not because it can be done that it should be done.
My gut feeling? The typical LOB/Enterprise applications that require mouse/keyboard input will not be Metro applications – they will look, feel, and be developed just as we do today, web-based or desktop-based, and will be run through the regular desktop in Windows 8.
Conclusion?
With Windows 8, we get a new type of application: the Metro style app: touch-centric, Win 8 only apps, using a new WinRT stack, which can be developed using XAML/C# or HTML/JavaScript (keeping in mind that those apps will not just run in a browser, or in Silverlight). This Metro style version of Windows is, in my opinion, quite similar to what we’ve got with iOS/Android-based devices. The thing Windows 8 has going for it is the ability to switch between Metro & regular mode, but we’ve got to keep in mind that these are 2 very, very different environments, from a user POV AND from a development POV.
But for the most part, and for the majority of applications that are built today by companies as the one I work for, there’s not that much that changes: we typically buildLOB / Enterprise apps, not very suited for the touch-based, small application, consumer-like approach Metro is tailored to.
The best advice I can give anyone who’s building applications today: build a decent, standards-based service layer, and tailor the frontend to the devices it has to run on, be it a regular web app, a Silverlight OOB app, an iPad or iPhone app, or a new WinRT Metro Style app. The “build once, run everywhere”-dream should be put to rest. The best user experience is, and stays, a native experience.
