I’m stuck. I have been stuck for 3 years. I am tasked with upgrading a core business product from ASP into .NET. This project is a larger project within which I am tasked with smaller tasks to address customer requirements on other business application solutions, so development time is not as consistent or contiguous as I would like. We work with what we are given, and I have no complaints. This task seems a simple proposition. .NET, after all, is a very mature and comprehensive framework. What it lacks is more than made up by third-party tools or open source solutions. The server is writing itself. My problem is the user-interface.
I was asked to maintain the general user-interface functionality, but without prejudice of improvements, sacrifice or change. But the user experience should be similar. This is fair enough, but when the application is a product of 10 years’ evolution, written in ASP and is in everyday use by businesses who are familiar with the user-interface, it becomes challenging. Fundamental change from the user’s point of view was not an option.
To give you a background of the product user interface, there are a number of modules, each of which interact with a core data-set. These modules each have their own user-interface, exposed in the user-interface through a set of mini-panes and tab-sets. As you can imagine, it quickly becomes a busy interface.
So I started thinking about an HTML4+JavaScript implementation, using external toolkits to keep a decent pace of development and avoiding re-inventing the wheel (for example, Telerik controls). In maintaining the comprehensive – but complex – user interface previously developed in ASP and IFRAMEs, but using modern techniques such as JavaScript, etc., demonstrations quickly started to become slow, bloated and stuttery. This was particularly acute in the desire for the users to customise their own interface. Resizing panes, storing and managing the whole experience was a significant task. Was HTML4 really up to the job of such a comprehensive user-interface?
As a shining light from the heavens, then came Silverlight. A robust client-interface for PCs AND Macs that can run within and outside a browser. It uses C# code I’m familiar with, XAML is vastly simpler for me than HTML and CSS and because it’s a plug-in, it works the same everywhere. This was my chance to implement the same, though improved, user-interface as our legacy product and know that the final result would be robust, fast and somewhat portable. The learning curve was steep in the first week or so as I had to understand that I really was separated from the server bar the thinnest of WCF connections and introducing an asynchronous mind-set, but the prototypes I was producing were solid, attractive and fast. My development plan was safe.
Then came “that” keynote by Bob Muglia about HTML5, and the industry’s highly insightful journalists started to announce the death of Silverlight. And so it was that Twitter, the blogosphere and my colleagues started to take those highly insightful journalist’s articles and tell me Silverlight was dead. I should switch NOW to HTML5, as my Silverlight experience and career was headed south. I, however, am intelligent and I like to analyse that which I read, rather than devour it uncritically. I was able to understand that though Microsoft are very good at some stuff, they are crap at marketing that very same good stuff. So in completely missing the point of Silverlight, both Microsoft and the insightful journalists surrounding the industry created a cancer within Silverlight. Either way, its future was now uncertain, even if it was technologically superior and well-fitted to our market – the small-medium business with little IT support/infrastructure.
I refused to listen. Silverlight was vastly quicker to work in, resulting in lower direct costs to the business (us). HTML4/5, JavaScript and CSS is a fragile set of half-implemented, somewhat competing technologies that requires significantly more time in implementation, tweaking and testing across often incompatible browsers.
Now, however, I cannot refuse to acknowledge Silverlight’s future. But nor can I justify the higher development costs of HTML4/5. Sure, the naysayers have had their day, but it is not this that has changed my thoughts. It’s the appearance of the iPad and the inevitable invasion of otherwise sensible board-rooms with “sexy tech.”, and the very users that need to use our software buying in to that technology. Apple have been stoic in their reluctance to allow plug-ins, all but killing the plug-in model dead. It is this that served Silverlight its notice, not Bob Muglia, the naysayers or Microsoft not planning a version following the latest version 5 release.
Something had to give.
I decided to get radical. It was time to throw away the baby and the bathwater. And that was the user-interface as it was was not sustainable. It was too busy for HTML. So maybe, taking on board the newer user-interface concepts that we’ve seen in the last few years, such as Metro, iOS and Windows 8, we could simplify. After all, who really needs to see all information about an asset, all the time, ever, on a single screen? The Windows 8 notion of a two-pane screen as opposed to a multi-paned desktop might be the catalyst I would need to switch user-experience strategies, and sell that radical switch to management. So long as those two panes (or tasks) can be chosen by the user, they are still able to do their job. Such a simple user-interface then opens the product back up to implementation in HTML4/5. And it will work on sexy devices wielded by board-members. Ergo: it’s a user’s compromise, as opposed to a technology one. Sorry, the users lose.
So where has that gotten us? In 3 years, I’ve moved from a single unwieldy, slow to develop HTML solution to a number of smaller, product-specific “clients”. Can software developers claim less up-front costs, but having to write elements of the same interface many times? We’re certainly not insulated from political decisions by the heavyweights, such as Apple’s reticence towards plug-ins or Microsoft’s ineptitude at marketing their own products. If we write one phone application, we have to write 3 (one for each of the industry leaders), and play with the rules of the respective marketplaces which includes the inevitable latency in approval and deploying updates. I still stand by my decision to adopt Silverlight, but for reasons out of my control (and those insightful journalists), its adoption will be in a modified form. Other than that, we’re in the hands of the gods which includes browser standards committees, marketplace rules, compatibility fixes and the next “sexy tech.”.