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.

 

start_screen

 

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. 

 

win8-platform-and-tools

 

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.

 Tweet about this on TwitterShare on LinkedInShare on Facebook

5 Comments

Christian

Very good article. 

Nothing is going to vanish, but something new in addition is rising. 

:-)

Dan Vanderboom

Your post seems to ignore two things. One, that Silverlight has great touch and multitouch support with free libraries; and two, that writing a single Silverlight app, delivered over the web to any user on any platform, is in a developer's best interest. 

Why would I choose to tie my tablet-touch-centric Silverlight client to a single platform, if it could otherwise very easily run on other devices? 

Instead of backing off with Silverlight on other platforms, Microsoft should be pushing as hard and fast as possible to create implementations to make Silverlight more universal and therefore more valuable to developers and their customers.

kevindockx

Dan, it's true that Silverlight has great touch and multitouch support, so you can write SL apps for touch (quite a few exist already). 

However, I don't completely agree with you on the second statement, as, imo, it's starting from the wrong premise: you're talking about what is in the best interest for the developer, while what should matter is what is in the best interest for the end-user.  Sure, as a developer, it would be nice to have 1 app that works everywhere.  But as an end user, that means you'll end up with an app built for, for example, mouse/keyboard input on a tablet or smartphone.  And, well, that's a very sucky user experience.   

That said: what is reusable, is skill.  If you know XAML, you can build apps for Metro.  If you know javascript: same story.  Next to device/platform-specific calls, the syntax is more or less the same, so it's quite easy to start developing for those environments.  And if you put your logic behind a service layer, the only thing you have to rebuild is your presentation layer. 

And you should rebuild the presentation layer: different devices require a different UI.  I absolutely hate using my phone to look something up, only to realise the site I'm visiting hasn't got a mobile version; let alone having to do that with a LOB application.  What I, as an end-user, want, is an app tailored to the device I'm using.

kevindockx

*Addition: I'm quite confident RIA Services is going to be a great fit for such a shared service layer – works like a charm with Silverlight, but it's also got SOAP & OData (read) endpoints, and next to that, through the toolkit, there's a RIA/js-implementation for use in HTML-based apps through JavaScript; and it's even being optimized for use with Win 8 Metro style apps.

Dan Vanderboom

I'm not saying that developer needs take priority over user needs at all. They're not actually in conflict. If a developer's needs are met, and great tools made available, the developer will have more options, more expressive power, and so on. Better tools and platforms make it easier for the developer to be productive in solving user problems or taking advantage of user opportunity instead of spending a lot of time writing boilerplate code and going through lengthy construction rituals. 

Platform specific assemblies are sometimes necessary, as is custom UI based on form factor and interaction mode; but 

 in many cases, a universal UI *CAN* be used across device classes (simple scenarios), and (B) the same UI often makes sense on the same class of device but on another OS/platform (Windows vs Android tablets). 

Think about this: Moonlight on Android was shown off at least as early as MIX11, which by the time Windows 8 and those tablets ship will be Summer 2012 at the earliest. I'm guessing Moonlight will be fairly capable by then of supporting a majority of the core functionality, if not the entire Silverlight runtime. (Miguel de Icaza and his team are  amazing, and are driven to expand the reach of .NET and Silverlight on other platforms.) And how long before Microsoft, Xamarin, or another company decides to make an iOS browser with a Silverlight runtime? 

With support for both Windows and Android tablet devices, the Silverlight app with the greatest reach will be the Silverlight website, not the Silverlight Metro-only app. Many of these Silverlight web apps will be touch-centric, well at home on a tablet. If you know you want your app to run on these other platforms, are you really going to want to create all separate projects, one for Metro, and another one created as a normal website so it can run on Android? I sure wouldn't. I want to build one product, in one VS solution, and have it run as many places as possible. I can always swap out UI views for different screen sizes, orientiations, and input methods: one set of view classes for phone (touch), one for 7" – 11" tablets (touch), one for desktop (touch + keyboard + mouse). Platform-specific plug-ins can then extend functionality on a given platform. 

Don't get me wrong. I'm not saying there's no reason to write a Metro app. For Windows-specific applications, to interface with uncommon hardware or when it's an internal company app where Windows machines are mandated, Metro and the Microsoft App Store should prove to be a great opportunity for many developers, especially independent developers. But you have to be careful with incentive systems: with Microsoft putting all the focus and reward potential into Metro apps and that store, developers will flock there. Is it because building platform-specific apps is in users' best interest? In many cases, platform agnosticism is the better choice. But there's no reward for that because it's in Microsoft's own best interest, a la profit motive, to lock you into their platform instead. Or so it seems at first glance. I actually think they'd be better off extending Silverlight's reach aggressively, which they can easily do addition to all their great HTML5 work. 

Microsoft has the resources to put Silverlight everywhere, or nearly everywhere. HTML (and Flash, effectively) have had a near monopoly on apps/content with universal reach. Because of the lack of competition, they've evolved as a snail's pace. Having a fiercely capable competitor like Silverlight would only make HTML stronger. 

Comments are closed.