I’ve recently written a little application for Windows 8’s Metro-App platform: let’s call it Win8 Apps platform for the sake of brevity. Metro isn’t new (Windows Phone came out a few years ago), but it’s now part of Windows 8, thus going to be widely adopted as the de-facto desktop interface. My application is a simple slide-to-navigate image album: it allows portrait and landscape images (without zooming – more on that later), and allows embedded videos. Touching video-images once plays a video, and touching it again pushes you back to the regular image album view. Checkout the source code here at GitHub, or just fork it and have fun making your own changes!

After programming on Android and iOS for a few years, I can modestly judge that Microsoft is finally going in the right direction with their new Windows 8 App platform from the developer’s perspective. I can’t stress enough that my perspective written here is purely from a developer’s point-of-view, and not from a business or user’s view. I’ll go as far as saying that Metro isn’t the right GUI solution that the average user needs, though clearly computer interfaces and experiences absolutely need to be simplified, so in a sense Metro is a move in the right direction. Regardless, you can still flip to a classic desktop, so users aren’t forced to commit to anything. I wont go deeper into this subject, but solutions like Google’s Chromebook are the best approach for the average consumer (though enterprise solutions are still a Windows winner). The average computer user really just needs a browser, which has only become increasingly powerful as business apps (Office, Image editing, etc.) are popping all over the web.

Now down to the core discussion: how is it to program in the new Win8 App environment?

The Win8 App platform succeeds by implementing a clean platform and tool-suite: its new run-time environment, libraries, methodologies, and interfaces are all independent of one another and well modulated. All the classic .net languages (C#, VB, and VC++) are ready-to-go for app development  with the added new language Javascript! What’s particularly nice is each language embraces their respective strengths, but also doesn’t stray too far away from a general standard that the .net library provides. I felt that Javascript in particular overly embraced lambda-functions, but the end-result is always the same. The library namespaces make sense, though Microsoft (and this is a common fault with their past .net versions) has overly embraced object-oriented programing (OOP).

There is almost an over-modularization of components and classes, an annoying fault also found in the Java SDK libraries. Something as trivial as setting how long an animation lasts should take a native type (float, for seconds). Instead, the type required is “Duration”, which can only be constructed with a “TimeSpan” object. Alternatively, you can construct “Duration” with a “TimeSpan” static function that converts seconds direction to a TimeSpan. Clearly these classes are needed in a variety of other applications, but not necessary for a simple argument like an animation’s time. This is only the tip of the iceberg; there are many, many other abuses like this, which I call “object-oriented verbosity”. Another frustration would be that over-abstraction of clases: the UIElement class (the base type for renderable / interactive screen elements) does not directly provide position or size, but instead provides a matrix which may or may not be a pointer to a specially-derived matrix with the properties you want. What this means is that if your UIElement is rotated and translated, but you have yet to define a size, the matrix object owned by UIElement will strictly only have the rotation and size properties. It is critically important for any GUI library to be as up-front and accessible as possible, regardless of backend or platform.

Though the language-model/library interface is a bit weak, at least the XML-language forms make up for crazy-easy development. Past platforms with Microsoft commonly had a form-modeling editor, like a GUI mockup system. With .net, you could place a button, double-click on it, and have code auto-generated for you! Microsoft has done this well, but the older form-editor were just visual tools, not something easily changed through text (a small difference, but a huge impact on development time!). Now I can cleanly move a button either in the GUI editor (now a separate tool!). Want to catch when a user clicks a button? Just set the button-tag’s “PointerPressed” property to the name of your function. All of this really conforms to the Model–View–Controller: often dismissed as boilerplate code, this approach to GUI-programming is incredibly important since mobile platforms (Win8 Apps included) re-use many screens and are quick to change forms, fits perfectly with what is required in development.

An aspect that I couldn’t decide if it was good or bad was the inclusion of CSS style-definitions in GUI forms. XML, much like HTML, lays out a document’s content, but shouldn’t define how these elements look in-line since many styles are often repeated. Thus, a CSS file makes sense, yet, if the platform has committed to an alternative to HTML, why not commit to replacing CSS with a less verbose language? CSS is powerful, but often hard to read and maintain – it makes more sense to allow some sort of repeatable style definitions within the source XML, or at least have the ability to include other XML files in-line. Then again, if developing an Win8 App is more like developing a web app, at least there is a strong and large shared-base of knowledge all over the web.

Overall, Microsoft has done a great job simply because they are committing to the right direction: cleaner developer tools, a new XML layout system, and all based on the powerful .net platform. There are apparent weaknesses, such as the difficulty of programmatically moving content, which is trivial for Android and iOS. Microsoft simply needs to refine the platform, improve documentation (it was pretty hard to distinguish between this new platform, code from older .net versions, and Silverlight APIs), and most importantly: get the average consumer using Windows 8!