Colin Eberhardt's Technology Adventures

Windows 8 – An OS of two halves.

September 15th, 2011

In this blog post I take a look at Windows 8 on the outside, from a user perspective; and on the inside, from a developer perspective to see how it will change the way we develop with Windows on tablets, smartphones and the desktop when it is released next year.

In Anaheim, California, the Microsoft //build/ conference is drawing to a close. And as the attendees head for home, with their shiny new Samsung tablets under their arms, the news of Windows 8 and the impact it has on end-users and developers is starting to sink in around the globe.

There is no doubt that the impact of Windows 8 is going to be very large, it heralds the biggest change in the Windows architecture since 1993 and from an end-user perspective it is like no other version of Windows before it.

So why such a radical change to both the UI and the architecture? and why now? The answer to this question is quite simple … tablets. Previous versions of Windows have been targeted primarily at the desktop, laptop and netbook form-factors where the primary input devices are mouse and keyboard, and memory, disk-space, CPU performance is aplenty. Tablets have made the odd cameo appearance in the history of computing, but it is only recently with the launch of the iPad that they have suddenly become mainstream.

To take the Windows OS to a tablet it needs to be stripped-down, made faster and support multi-touch (or touch-first – a new Microsoft buzzword) and with Windows 8 Microsoft have done just that. With the requirements of a tablet interface being so different to a desktop, how have Microsoft reconciled these differences? The answer is a little surprising … they haven’t! They could have launched a dedicated Tablet Windows OS, just as they have done on the mobile with Windows Phone 7, but instead they have launched a single OS that works for both tablet and desktop. As a result it has something of a split personality. You can choose to run either the Metro or the ‘classic’ desktop UI on your tablet computer and you have exactly the same choice on your desktop.

An end-user perspective

The Windows 8 user interface uses the same Metro style that Microsoft introduced with Windows Phone 7, bright colours, clean edges, a lack of drop-shadows and other adornments. The style is heavily influenced by fonts and designs used for road and street-signs. The same concepts of clarity-at-a-distance translates very well to a small smartphone screen and should be equally at home on the tablet.

When applications are launched they run full-screen, with a similar multi-tasking model to Windows Phone 7 where hidden applications are suspended. These features, combined with the fast shutdown / restart times make sense for tablet users where limiting the work that the processor does will significantly enhance battery life.

You can run multiple applications side-by-side in a split-screen mode:

The current preview of Windows 8 has a few of the familiar applications available in the new Metro-desktop, these include IE which is now chromeless, i.e. it is permanently in full-screen mode. Gestures are used to reveal the open tabs or URL. Notably the Metro IE does not support any plugins, i.e. Flash, Silverlight – more on this later!

Metro applications for Windows 8 are distributed via the Windows Marketplace in much the same way as they are for Windows Phone (and iPad, Android etc…).

The Windows 8 UI clearly has tablets in mind and recent reviews by Engadget and Gizmodo seem to indicate that the experience is very good and agree that when released it could be a serious competitor to the iPad.

However, hidden behind the glossy Windows 8 UI sits the more traditional Windows 7 style desktop. Simply click (or touch) the desktop button and the old-familiar Windows desktop appears. It almost feels like the desktop is an app running within the new Metro UI – you can also run a split screen which combines the Metro and desktop UIs:

Interestingly if you want to run IE with plugins, there is a fully-featured version of IE present on the desktop. Try explaining these differences to your grandmother!

For a tablet, Windows 8 gives you the best of both worlds, an immersive and tactile Metro interface, plus the old-familiar Windows desktop.

On the desktop, Windows 8 does feel a bit strange. Metro applications are designed to work with the mouse and the keyboard, so it functions just fine, however, on a desktop monitor the Metro UI feels like a bit large and a touch gimmicky. The Metro concepts work well for small screens, but in my opinion are less effective on a large desktop monitor, especially in the absence of touch. I doubt it will make a big impact for desktop users, but at least they have the choice! When used on a PC with multiple monitors the new Metro UI is confined to a single screen, again further illustrating its tablet focus.

A developer perspective

Windows 8 marks a radical change from the outside, but what about on the inside? What is the developer story?

One of the most important diagrams revealed in the keynote is the Windows 8 architecture diagram:

It is clear that the split personality of Windows 8 runs very deep. In this diagram you can see that Metro style apps and desktop apps share the kernel, but nothing else. This is a pretty significant change in Windows architecture; Metro apps are finally free of the Win32 APIs which .NET has been built upon.

The APIs for developing Metro apps reside within the WinRT. A few keys things to know about this new architecture are:

  • WinRT applications are chromless, fullscreen, with no pop-up or modal dialogs
  • WinRT is an Object Oriented replacement for Win32
  • WinRT is very similar to .NET, however a number of APIs such as file I/O, security etc… are not present.
  • You can develop with C++, or C# etc… in much the same way as .NET applications
  • The UI defined using XAML, as per WPF and Silverlight
  • You can potentially port Silverlight applications to WinRT by changing a few namespaces
  • JavaScript is a first-class citizen of Windows 8, using a HTML UI

The above already tells us a lot about WinRT and Metro applications. My first thoughts are that they are much more similar to Windows Phone 7 applications than desktop WPF applications. They live within a sandbox which uses a restricted subset of APIs, you certainly cannot write a virus checked or hard disk partitioning tool with WinRT!

Furthermore, when developing Metro UI apps, Visual Studio ‘deploys’ your application too your Windows 8 Metro desktop in exactly the same way as it does with the WP7 phone.

So what about existing .NET applications? The important thing to know is that all the ‘old’ APIs are still there. Your WPF, Silverlight and WinForms applications are safe! There were also a few new WPF features announced at //build/ as part of .NET4.5, but they are not very interesting, it is clear that Microsoft has been putting its energy into other things.

The JavaScript / HTML5 story is a bit of an odd one. Clearly Microsoft has embraced these technologies, with JavaScript having full access to the WinRT. Furthermore, they have added APIs for creating Metro UIs with HTML. However, I am not sure why someone would want to use JavaScript to create Windows 8 Metro applications? The main strength of JavaScript and HTML5 is the portability due to its support on a wide range of browsers, tablets, phones, etc… The Windows 8 JavaScript Metro apps are ‘tied’ to WinRT so are in no way portable.

Questions …

Lots of questions … the rather complicated nature of Windows 8 has resulted in quite a lot of confusion.

Is Silverlight Dead? – this was probably the most oft asked question before //build/ and it is still being asked. The news that the Metro IE10 will not run Silverlight is certainly not good news for the technology, however, it does not mean it is dead – Silverlight is still present in the desktop IE10 browser (as is Flash). Recently Silverlight has been re-positioned as the technology of choice for more complex line-of-business applications, the types of application which sit better in the Windows 8 ‘classic’ desktop. Furthermore, whilst the Metro UI is leading the push into tablet computing, I doubt it will take off on the desktop. So, no, Silverlight is not dead, but it has unfortunately missed out on being part of the Metro UI for tablets.

There is a relatively simple migration path for Silverlight and Windows Phone 7 applications to the new Metro WinRT. This might work for full-screen Silverlight applications, but will not work for applications that mix HTML and Silverlight content within a browser.

Is WPF Dead? – Again, for much the same reasons as Silerlight the answer is “no”. WPF is a framework intended for line-of-business applications, and those belong on the Windows 8 desktop.

How does this impact Windows Phone 7? – it doesn’t. The next version of WP7 is going RTM shortly and there has been no change to these plans. In fact for WP7 developers Windows 8 is a great opportunity. The WinRT seems most closely related to Silverlight for WP7, so your skills and code are readily portable to the tablet.

Should I write my app as a desktop or Metro app? – this is probably the single hardest question that the Windows 8 preview has raised. As application developers we now have two very different ways which we can deliver applications to the desktop and tablet, either the new Metro UI, powered by the (deliberately) limited WinRT; or desktop applications using WPF or Silverlight. I think it will be very interesting to see how Microsoft tackles this problem with its own applications. So far the Windows 8 preview has Metro UI based Twitter, Weather and Social Networking applications and a desktop based Visual Studio. There is also IE which is available in both desktop and Metro, albeit with quite different functionality. Where will Outlook, Word, Excel sit in the new Windows 8?

I think there are rather a lot of applications that will want to make use of both Metro and desktop UIs. Take Outlook for example, you could imagine a simplified Metro interface sitting on one of your monitors, but a more feature rich desktop version available on the other.

One other point worth considering is ‘reach’. It will take a long time before everyone is running a Windows 8 PC, so if you choose to deliver your application as a Metro app, you are restricting yourself just to the Windows 8 user-base. However, if you are targeting the Windows tablet, you can of course guarantee that they will run Windows 8.

Conclusions

Windows 8 presents a significant change in the way we develop Windows applications. The split personality of the Windows 8 user interface and architecture is going to cause confusion on many levels.

The technical implications of WinRT and how it relates to .NET are slowly starting to become clear, thanks to great blog posts like “WinRT Demystified”.

Personally what I think will take a little bit longer to understand is how we design applications for Windows 8, as we start to discover what works well in Metro, what should remain on the desktop and what we deliver to both.

Regards, Colin E.

Tags: , , , ,
Posted in Uncategorized | 7 Comments »

Can Microsoft ‘fix’ JavaScript and make HTML5 applications viable?

August 16th, 2011

Microsoft’s recent change in stance over Silverlight, promoting HTML5 as “the only true cross-platform solution for everything”, seems to have sidelined Silverlight as a niche framework. This has understandably caused a great deal of upset and confusion in the .NET development community. Despite this, Microsoft are remaining steadfast and tight-lipped about their vision for tighter integration of HTML5 into Windows 8 (and as a result just how side-lined Silverlight will be), until the BUILD conference next month. Recently I have read numerous blog posts about the difference between HTML5 and Silverlight, and how to select the right technology for your development, however almost all of them seem to ignore the great-big thorn in HTML5s side … JavaScript. In this blog post I will explain why JavaScript is such a big issue for Microsoft and what it could do to solve this.

That HTML5 will be a huge success is a given. The specification is not finished yet; the parts that are finished are not fully-rolled out, however it is making technology headlines on a daily basis. The HTML5 buzz has also been felt by both technical and non-technical managers, who you will often find asking, “why aren’t we creating HTML5 applications?”. Pointing at the unfinished specification is a little unfair on HTML5, you can reliably use a number of the APIs right now, and they will certainly provide a ‘boost’ to your current web-offerings.

HTML5 is a real mixed-bag of features, from the complex, such as canvas and video, to simple semantic markup improvements and a powerful set of CSS features. Because HTML5 provides a spectrum of features from the simple to the complex, I don’t doubt that every new site will be using HTML5 in a few years time, you simply have to add rounded borders or a <header> tag to earn yourself the coveted HTML5 badge!

One concept that underpins the HTML5 specification(s) is that of client-side web-applications. The server-side web-application, where business logic and presentation logic reside on the server, spitting out markup (sprinkled with a bit of JavaScript) are becoming an architecture of the past. The model where the server exposes business logic as a service makes it much easier to provide a front-end on a range of devices (mobile, tablet, desktop), a range of operating systems (Windows, iOS, Android), allows the effective use of client CPU, and provides a more accessible service that customers can integrate into their own application. From my perspective the most significant undertone of the HTML5 specification is that it supports this model.

The problem is that the name ‘HTML5’ can be a little misleading. Whilst the specification has much to do with HTML, it has much more to do with JavaScript. In fact, many of the HTML5 APIs have nothing to do with presentation or layout. Any article which compares HTML5 and Silverlight, without focussing on JavaScript is really missing the point.

So, what is my big issue with JavaScript?


Image used under Creative Commons Licence from Flickr

JavaScript was hastily developed as a language for scripting the web. Unfortunately it has not evolved much since its inception. Certainly the APIs that surround it have evolved, including the DOM APIs, HTML5 and popular libraries such as jQuery, however the language itself remains largely unchanged.

The big issue with JavaScript is that it is not well suited for the development of large applications, and if we shift to a model where the server provides a service which is consumed by the client web-application, this necessitates a lot of JavaScript code. I don’t want to go into all the gory details of the problems with JavaScript, but here are a few:

  • Many language quirks and gotchas (see this article on codeproject)
  • A lack of ‘familiar’ object-oriented concepts (I am not going to make the mistake of saying it is not an OO language!)
  • A lack of dependency management
  • A lack of organisational structure (namespaces)
  • A very small ‘base’ library (for example no event support, string formatting, etc…)
  • It is not strongly-typed
  • A confusing array of patterns for solving some of the above!

This list is certainly not exhaustive; rather it is just a brief illustration of some of the obstacles that JavaScript presents to the developer of complex applications. Many of the items listed above are features of the language that are advantageous in a simple, scripting context, but when used to develop complex applications they are quite troublesome.

Another issue with JavaScript is not so much the language itself, more the attitude of developers towards the language. Because of its quirks and its predominant usage as a language for scripting web-pages (with the usual “google → cut → paste” approach) many developers simply don’t bother learning how it works. I have interviewed many job candidates who list ‘JavaScript’ as one of their skills, yet they cannot describe the difference between the binding of the ‘this’ variable between JavaScript and C#/Java.

There are numerous JavaScript frameworks that go some way towards solving the above issues … filling in the gaps. This is an area that Microsoft has dabbled in before, with the Microsoft Ajax Library adding inheritance patterns and .NET style libraries (albeit with a very clumsy, verbose and convention-heavy syntax!).

Whilst the list of issues above presents a challenge to the JavaScript developer, they provide just as great a challenge to the tool providers. Many features of existing IDEs, Intellisense (auto-completion) and structured views of the code rely on language features that are absent from JavaScript. Again, Microsoft has provided some innovations in this area, with pseudo-execution of JavaScript code providing some Intellisense support. Unfortunately this neat feature, which works well if you have all your code in a single JavaScript file, is less easy to manage on a large, more complex application. From personal experience I find Visual Studio adds little value to my JavaScript development experience, I am equally happy with Notepad++ and JSLint!

So when Microsoft announces their tighter integration of HTML5 / JavaScript into Windows 8, what innovations are they going to announce?

Personally, I think if Microsoft is serious about HTML5 and its potential for client-side application development they need to do much more than just add CSS3, canvas and video support to ASP.NET. They need to support the client-side application model, where ASP.NET no longer has a stake. To fully support this they need to ‘fix’ the problems with JavaScript.

One of Microsoft’s most prized assets is Visual Studio, their investment in tool-support allows you to use the same quality tooling for developing in a wide range of languages (C#, VB.NET, C++, F#, …) and frameworks (WinForms, MFC, WPF, Silverlight, ASP.NET, …). To fully embrace HTML5 / JavaScript it has to be fully embraced by Visual Studio. But therein lies the problem, the lack of namespacing, familiar object oriented concepts, strong-typing and base ‘class’ framework makes this a challenge.
I think the worst thing Microsoft could do is add their own JavaScript framework to the mix, further fragmenting the JavaScript development experience. Thankfully they recently adopted jQuery within their ASP.NET framework, showing signs that they are willing to work with existing open-source frameworks. So if they do not announce a new JavaScript framework, what could they provide instead?


Image used under Creative Commons Licence from Flickr

Microsoft’s Scott Henselmann has published a couple of interesting blog posts about the concept of JavaScript being the assembly language of the web (or the JVM of the web depending on your perspective). His second blog post included comments from a number of JavaScript thought leaders including its creator Brendan Eich who said “Believe it or not, classical OOP languages — especially ones with not-very-expressive static type systems — are not the only way to build large apps. It can be done in JS, but it’s harder than it ought to be”.

Google have already made some innovations in this area, the first is Google Web Toolkit (GWT), which allows developers to write Java code (using the powerful Eclipse IDE), which is compiled into JavaScript. The second is Google Closure Compiler, a JavaScript to JavaScript compiler / optimiser that provides type checking via annotated comments. It is this area that I think Microsoft should be investing in.

Microsoft could create a C# (or VB.NET etc…) to JavaScript compiler with an accompanying set of .NET base-class libraries. This would significantly boost Microsoft’s JavaScript offering in that it would be fully supported by Visual Studio, providing the developer with the quality tooling that they are used to when developing using other .NET frameworks. Furthermore, the C# to JavaScript compiler could be used to compile the existing .NET base-class library giving developers a large suite of familiar libraries for use within their code. You could event support C# to jQuery using a fluent Linq-style API!

So how would this work a runtime? When used on the internet to write applications for the browser or mobile browser, a set of C# DOM APIs could be created that compile to the ‘native’ JavaScript equivalent. HTML and CSS3 could of course be included directly within the project as resources.

On the desktop there are a few options, HTML could certainly be used as the presentation technology, but there is of course another option … XAML. Microsoft has clearly indicated that XAML will be part of Windows 8, considering that Silverlight 1.0 was XAML + JavaScript, it is clearly possible to have a XAML UI backed by JavaScript code. Although, it would seem a bit convoluted to compile C# to JavaScript to interact with the UI generated from XAML when C# APIs exist already!

In summary, I feel the current focus on HTML5 whilst ignoring the very real JavaScript issue is going to cause adopters of this technology a lot of pain. Whilst this technology set gives a fantastic boost to interactive websites, using JavaScript for the development of large client-side applications is an expensive option. My hope is that if Microsoft really embrace HTML5 they look beyond simply adding tag support and tooltips and address the real problem … JavaScript.

Regards, Colin E.

Tags: , ,
Posted in Uncategorized | 21 Comments »

Silverlight UK User Group Presentation on Cross Platform XAML

July 1st, 2011

Earlier this week I presented a talk to the Silverlight UK User Group on cross-platform application development with WPF, Silverlight and Windows Phone 7.

Thanks to Gergley Orosz for these pictures

Thanks to all who attended my talk. Here is a copy of the presentation I gave:

You can see the Windows Phone 7 XAML Finance application which I demonstrated in the following video:

The Silverlight version is also available online.

Finally, the sourcecode for the simple cross-platform Twitter application I demonstrated is available to download: CrossPlatformDemo.zip

Regards, Colin E.

Tags: , , ,
Posted in Uncategorized | 2 Comments »

White Paper: Flex, Silverlight or HTML5? Time to decide…

May 5th, 2011

When meeting current and prospective clients the subject of web technology choice often arises. There has been a great deal of confusion and uncertainty out there, even before Microsoft’s perceived change of stance with respect to Silverlight emerged.

This white paper is intended to help technology decision makers come to an informed choice when faced with this difficult decision. You can view the paper below, or download it in PDF format: Flex-Silverlight-HTML5.pdf (1.3 MBytes)

Thoughts? comments? leave them below …

Regards, Colin E.

Tags: , , ,
Posted in Uncategorized | 18 Comments »