Which UX Platform would you bet on?

If I could get paid for each time I’ve been asked which UX technology/platform should one bet on in order to produce the next generation of software in day to day business – I’d be quite well paid!

I don’t have an answer, and what’s really sad about that is that I should have a few answers not just a single one.

Today, you’re spoiled for a choice of technologies to help you produce some user experience namely for mobility. Since the introduction of the iPhone and iPad it’s arguably put something we’ve all kind of known into the mainstream hands, which is “experience matters”. Businesses are now keen to ensure that the next piece of software they produce works like it would on an iPad or iPhone (the amount of times I’ve been given a brief that uses that as its baseline for success is almost 90%+).

Why the issue in selecting today then? Well let’s look at the brands in question.


You cannot disagree that Apple’s influence on the UX discussion has been quite loud and obvious. Almost all phones and tablet devices have pretty much copied the entire existence of their products to the point where even though they hadn’t invented some of the ideas, they now look as if they did. Having said that, Apple still is a prescribed existence in that in order to play on their hardware you have to develop & design to their standards. You also have a limited amount of agility in order to take the device and slot it into various enterprise/industry verticals (mining, finance etc).

Distributing your solutions via a closed private cloud like existence can be done with iPad/iPhones but its still a bit messy in deployment. Furthermore inside almost all large organizations your cubicles of developers don’t have “Objective-C” in their resumes.

Whilst it has become the baseline for what a device driven UI should look like in the eyes of most business and technical decision makers, it’s still got a lot of latency and turbulence around its software development life cycle (i.e. it’s fast become a specialist skill not so much as a mainstream one).

Google / Android.

Google have managed to hold strong with their device platform story, that is to say their entire development and design pipeline isn’t that bad. Having said that I’ve seen, heard and been in enough meetings to see it being instantly rejected and it has to do with versioning and security as the core reasons for rejection (right or wrong).

Furthermore Java development at its core isn’t something you see go hand in hand with design focused teams, so again you have this issue with as stated by Apple around specialist skills vs. mainstream skills mixed with some market acceptance issues.


Just read my blog for a few pages you’ll see a theme emerge. Microsoft had a few ideas around what the UX space should look like, they put some bets on the table around these ideas, they got some semi-successful acceptance worldwide on these ideas but now they’ve kind of hit reset on the said ideas, taking two steps back and pissed the developer base off in the process.

To summarize, Microsoft has a whole new round of trust issues around long-term decision making, their tooling is good enough to build large enterprise applications with and lastly they still have a healthy developer base that have mainstream skills in C# & XAML.

The downside is their entire strategy around what you should or shouldn’t do going forward is out of control and requires a focused mind to unravel.

What I would say though is that Windows 7 is likely to be around and in a healthy state over the next 3-5 years and I think the hardware market will still look into ways in how to socket Windows 7 as their native OS when possible (for business, not so much for consumers). Given Windows 8 Surface is making their own hardware it could also be a negative for Microsoft, so whilst the only real option for hardware makers is to adopt Windows 7 or other, this in turn puts a long-term question mark around whether or not Silverlight or WPF should be something you double down on?


I often praise Adobe more than I have in the past as despite how close they came to overtaking HTML as rich media technology platform, they have managed to regroup nicely around being focused on tooling.

Given the turbulence above this company may solve the problem through tooling so it could even abstract the decision making process around which is the next bet by simply saying “it doesn’t matter, just use Adobe XTool”.

It’s still a long way off before that idea is realized, but none the less Adobe Flex / Flash aren’t something one should ignore outright. It still has some legs and although its clear Adobe Flash and iOS will never meet, they do meet however on Android and potentially Microsoft Windows device(s).

Despite Silverlight’s attempt to knock Adobe Flash out of the decision process if anything Silverlight’s demise has strengthens the runtime’s position further.


I’m going to say that this has become a brand not so much a technology; in that when you say “HTML5 is the future” you’re not saying “these additional tags are the future” you’re actually saying “HTML, CSS and JavaScript are the future”.

It’s a brand now so with that I’d simply say that it plays well on all of the devices above and will most likely continue to do so. The developer base out there is pretty vast in its knowledge around HTML/JavaScript and the various frameworks they use to obfuscate the fact they are writing JavaScript.

However, if you have a subscription to most research companies around RIA in the past and present, you’ll see a theme emerge that is to say that in Enterprise (not consumer space) the whole JavaScript/HTML combination has left a very sour taste in their adoption loving minds. Furthermore the limitations and slow growth of HTML in general has also left concerns on the table that whilst it maybe a uniform technology set that helps shape UX, it’s still doing a lot of emulation and fakery to get to the point where most rich client technologies are today (HTML vs XAML vs MXML etc).

That’s all argumentative, so who’d you pick?

There the above working summaries overall and it really comes back to the question of making a decision. A decision like this is important and still necessary as when you start making architectural bets for the life of your next industrial grade solution, you need to line up how you’re going to present your connectivity to its vast user base.

Walking into a meeting and saying “all of the above” won’t fly, walking in and holding the posture of “right tool, right job” mantra also may make you feel like you’re a software mountain sage it does little for productizing ideas/solutions to a customer base who have a variety of IT environment(s) that are looking to your company as a lifeline to making the said decision.

Bottom line is someone somewhere has to be the one that says let’s go with “X, because…”

If I was asked today which one I’d pick out of the lot, given I’ve worked in all the above.

My bet for enterprise would be WPF for one simple reason – Windows 7.

Microsoft spent all of last year praising how successful Windows 7 was in terms of sales, record profits and so on. What I got from all that bravado was that whilst Windows 7 was stomping on Windows XP wind pipe, it also was replacing the old problem with a new. That is it won’t be something in which gets deleted from Enterprise machines that cubicle workers and field agents use today anytime soon.

That for me has a much further and greater ubiquity story than most either realize or choose to acknowledge.

iPads are definitely something that may get some traction going further in large business but ultimately it’s such a specialized decision that I think having those devices do anything outside of a HTML app in its first generation of solutions in the enterprise is something that I’d say isn’t a worthwhile bet (it’s still in pioneering mode).

WPF and WinForms will still have a much longer usage than most will also care to agree outloud but I think once Silverlights engines get shut down more and more the retreat position for most will be back to WPF whilst they wait for the whole WinRT story to stabilize.

Adopting WPF today gives you also some healthy amount of skills to target WinRT later on, but it also gets you into a position where there is a likely chance of some additional changes / upgrades should the WinRT vision fall flat (Which I’m thinking it may very well).

That’s what I’d say out loud, as I’d say this based simply on your HR recruitment potential, tooling story and lastly ubiquity related decisions that are made in organizations where little patience is given to solutions built in HTML of the past.

My opinion has now been noted, so what would you bet on and why?

Related Posts:

  • craigvn

    I would bet on HTML5. Not being tied to any particular vendor it is less likely to have the rug pulled out from under it’s feet. iOS is stable, can’t see Apple coming up with something new soon, but the vast majority of people are not running iOS machines.

  • anthony

    I see too that Windows 7 will play a major role in business in the coming year. However, due to the lack of clear strategy that Microsoft has over it’s UI systems, i wouldn’t touch anything from it (WPF/Sl and the like).
    I will continue to develop for Windows but for the company i work for, i decided to start using C++ and Qt, the best combination of power and stability. I really got sick that i have to re-learn some “new” stuff every now and then bacause Microsoft changes everything all the time.
    And as a plus, C++ expertise would be usefull in the Apple world (i develop in there too) as i can share much of the code between platforms.

  • Certainly not Android. It’s hideous, it’s a copy of Apple and the dev toolset sucks (but I’m biased coz for me anything built on Java pretty much sucks).

    My bets and personal investment are and will continue to be on HTML5 for web apps (and in a few years time for device apps too) and hopefully WP8/Windows 8/Metro. It looks nice for a whole range of content heavy presentation apps like news, catalogs, brouchures and even where a lot of input is required.

  • Our UI designs were heavily focused on WPF and Silverlight.  With the recent API churn at Microsoft we’ve started a slow retreat into HTML/JS/CSS.  Interestingly, the API which has remained the most stable for us over the years is iOS, and we expect further gains here too.  Currently, we support apps across iOS, Android, and Silverlight.  Surprisingly, HTML/JS was shut out until the recent debacle with Silverlight raised questions.  Internal efforts to support WinRT fall flat because the technology is tainted by association with Silverlight.  We made huge bets on Silverlight after NBC hosted the Olympic games using Silverlight.
    Thankfully, our web services based architecture translates nicely to a web 2.0 architecture with HTML/JS presentation.  All that we have to do is divest ourselves from XAML and we keep our Azure-based C# middle-tier.  Prior to the Silverlight shift in direction, we were a 100% Microsoft technology stack and we prided ourselves in it.  We lived, breathed, ate it. 

    With newfound interest in HTML/JS, you ideally make this ‘all in’ transition as an organization.  That is to say, if you accept that open standards HTML/JS is a good thing, then you decide that more open standards is a good thing.  The net result for us is that Microsoft is increasingly displaced from the technology stack.

  • I agree with you conclusion with a caveat…

    Your target audience will ultimately decide what stack you choose to work with. A perfect example is my role as a software developer for the Irish Food Industry. This is a massive market with huge revenue streams. Currently we are WinForms / CE based as hardware dictates the stack.

    We are looking to move to WPF for some projects and possible WinRT for a BI project. Some other skunkworks projects involve asp.net webapi with a healthy dose of js / html.

    Microsoft did not set this path for us, our industry, by way of hardware, did. There is a lot of hot air and chest pumping from all sides but realistically the choice will depend on your audience.

    If their is one piece of advice I can give anyone, it is listen to what the customer wants and decide based on that. If all our customers moved to Mac’s tomorrow or if Apple brought out an industrial grade scanner with iOS, you can bet your ass we are learning Objective C.

  • Russell_g_1

    I think HTML5 will eventually win.  Most applications could be built one way or another in HTML and once you’ve done that then they can be used from any device with a web browser.

    Having said that I do like the look of all this Metro stuff Microsoft is producing.  But there’s nothing to stop developers from using the same design ideas in their HTML5 apps.

  • Jorge

    The architecture of the app should make the ui an implementation detail, albeit an important one. The app should be structured so you can serve the same services over different uis, a good architecture is one that allows to defer the decision, the ui should be one of those decisions, as well as the database

    Having said that, and assuming that the app does not need access to the client’s hardware (i.e. the camera) then I’ll go with HTML5 because it is what will have the broader access (and there are pitfalls there too, I which we would stop the vendor specifc css attributes madness); otherwise, I’ll go with WPF as you do.

    Or Winforms if it needs to run on XP

    Or Objective-C if it needs to run in the iPad


    Never mind.

  • Nige

    Hi Scott, I just come come around to agreeing with your WPF argument.  I was a great technology but it never performed well in use, and I get the feeling it got flushed down the same drain Silverlight left the building by.  In business there is a new trend of supporting people’s own devices, and I hear cries from many executives who are trying to make excuses why the company should buy them an iPad, but there is underneath all of that noise a strong business case emerging for more portable and flexible devices.  They will start being used in businesses more, so for me the cross platform ability of HTML 5 makes it the strongest contender, even if it is undoubtably the trickiest one to develop for.

  • Rory

    Having built a substantial ERP solution on the .Net platform with a WPF front end I have copnsiderable experience around the challenges of meeting the demand of today’s consumer. The explosion of end point devices demands flexibility. Users and the companies they work for want small, mobile platformsfor the majority of the functionality they require. Sure there will be back office power users that want the experince and horsepower of a fat client running on a performance machine, but the vast majority of users do not want to be tethered to the desk in 2012. The issue is the choice potential devices is exploding, not consolidating. This ultimately means future products of any scope will need to be available on multiple endpoint platforms. The underlying architecture driving these types of solutions will need to consolidate business logic/rules and data on a common platform with extension through API’s. Whether building IOS, Android, or Windows apps the effort would be almost entirely UX for that device type. In my mind this is the only effective way to make the most of your development investment while meeting the demands of todays consumer.

  • In the near future, yes, there will need to a choice around handling an array of device(s) that meet target audience’s demand(s). Today however right now, gun to ones head, make the choice it’s hard to line up which of the “platforms” can meet that future goal. Each has a healthy variety of positive / negatives attached to the choice around future proofing for vNext device(s) – yet – none really are the silver bullet when it comes to matching Human Capital/Resources and Technology together.

    Each geographical location has a supply of n-developers who do xPlatform the most and scarcity of choosing bodies to fill a cubicle is one thing to also consider (despite potential of off-shoring the work, it still at times fails to fix the local bodys in local cubicles need/desire).

    Then once you establish your HR pool you need to factor in their software maturity around development skills. Not everyone in the team is an SDE II graduated from MIT so again you need to factor in your choice around scaling the technology to cope with rising pressures around balancing function & form?

    My choice with WPF factored in all of this and it’s not an ideal choice, its buggy, its got performance issues that are well documented and lastly its skill pool isn’t as high as it could be. It does however reduce complexity around  developer share and it does potentially pave the way for the C#/XAML retreat that’s going on in the Microsoft space. Given Windows Phone 7 right now is probably the easiest device to target when it comes to developing apps (childs play) it’s also fair to assume that Win8/WindowsPhone8 may continue that frictionless development so again, your WPF may come back as a re-investment.

    I’m not advocating that .NET is superior than the rest on offer, I’ve worked win Java,Flash,HTML etc since their respective births, so for me I’m choosing a selection based on rising customer demand, current software penetration assumptions and i’m also notcing that whilst Microsoft developer relations are basically fubar, the seamless way they are shaping the various frameworks to start being smater in the way they communicate between layers is something you can’t ignore beyond just the actual UX.

    Downside is they will unlikely ever get the designer to integrate with the developer(s) in a way that reduces friction.

  • WPF stopped production around Silverlight 3 or 4. Basically the entire WPF team were stripped back to bare bones and put to work on various other Silverlight / ASP.NET work stream(s). The main rationale was at the time that WPF was toxic and didn’t have a future given its developer share was around ~10% world wide (even though the surveys used to come to that score were severely flawed and in fact to this day, Microsoft will never truly know how entrenched it become or is as their main source of data is based on a tick box system that asks “are you thinking about WPF” not so much “are you working with WPF” and furthermore it’s asking the wrong people the questions!

    That being said…

    iPads definitely have what I call the non-technical excited. It’s a device that’s really created excitement back in UX + Software and it will set the bar for success for quite some time. That being said, HTML5 is not the answer to iPad success and anyone who’s built an app in iOS will likely testify to this. There’s limitations to victory there and whilst executive level gets all excited about having an iPad app generate their dashboards or balanced a general ledger there is still a graduation curve that needs to be factored in.

    If you’re building a LOB app that does nothing but forms and present static imagery or minor animations, sure you can pretty much choose anything you want here and win. If you want an app that starts to make use of various gestures or handling calculations / CPU expensive workloads then you need to graduate out of the browser and into a more native experience.
    I’m not saying you can’t do the above in JavaScript as I think it’s fair to say in the right hands JavaScript can do a lot of things for  a lot of solution(s). The key though is in the “right hands” and aspirations about being the greatest and mature software architect is admirable but in reality most cubicles do not have this in place. In fact most cubicles have a variety of specialised talent and i’d argue JavaScript + LOB Scalability has historically never worked out (according to Forester, Gartner research papers that go back to 2005-2011).

    HTML5 is the upgrade but the JavaScript is still the poison for the well.

  • Below client is irrelevant to the UX Platform choice. Given the patterns emerging around Bindable Views then having a disconnected client strategy is kind of an assumed state.

    The problem comes today, right now is if a gun is held to your head to choose for the next 3-5 years which platform do you choose is the question. You have to direct your troops of developer(s) in a cubicle to File-New-Project.. on a tool and in a language you can iterate / grow from.Right tool right job logic is great for conference speeches and what not, yet if your in a company that builds software for a variety of verticals then you in turn are most likely the one to influence the hardware selection (ie its not reactive but more proactive). Now comes the choice that factors in your hardware selection, HR skill pool within your various location(s), budget & shipping schedules and lastly and more importantly modular / skinability concern(s).

  • I think you maybe right but I’m cautious of declaring HTML5 the victor. We saw  a similar bubble of excitement around Ajax as being the silver bullet to the same set of problems. However it has continued to fail within the Enterprise and thus the reason Microsoft turned towards XAML/C# as a way of fixing this issue.

    Adding more tags to the HTML specification may solve some of the XAML specific concerns but the original problem has not been solved when it comes to overcoming JavaScript as a language that will be used to replace features you kind of get for free in thick client(s)… so we’re back to the whole thick vs thin client programmable API’s that are consistent, scale and have appropriate level of tooling behind.

  • I’d love to come back to you in a year or so after being in the trenches with the HTML/JS. That is I’m curious to learn more on that journey, what you found worked, what you realized was good/bad and so on. I think the intent is positive that HTML/JS seems to be the answer to the thick-client retreat yet, has this worked out as being the right choice? how does the current solutions match parity with the future HTML/JS vision of tomorrow.

  • Jorgeleo

    Hi Scott,

    I was not going to “the right tool for the job” argument, I was going more for “Don’t answer the question untill the very last moment”. My comment was a bit tonge-in-chick, but there are other people that explain this approach better than me. And it is an approch that I not only follow, but it has given me excellent results. I recommen whatching this video:


    Someone else’s experience pointed out: “Thankfully, our web
    services based architecture translates nicely to a web 2.0 architecture with
    HTML/JS presentation”. The API was what survived different UI waves, so I think it serves as an example that the UI needs to be so thin that changing it does not means a lot of effort.

    Recently, in one of my projects that the client felt it was very UI center (generating and calculating over chart diagrams) came a request for making it scriptable, they wanted to automate the application, and also probably move it from winforms to html5. Because the model was laydown first, the scripting was really easy (less than 1 week including a small embedded script editor), and creating an html 5 ui around will be a matter of what funcionality do we want to expose, not how we need to change the current functionality and what will break.

    I am on the camp of “The UI should be an implementation detail, not part of the center of the project”, so my directions to my troops is, create a dll, a test project, and lets make sure the model is sound, ui and db are only interfaces.

  • Aaron

    That’s a gutsy and savvy move – more power to you!

  • Aaron

    Scotty, you are right on so many counts. But…MSFT’s feckless behavior (you can tell from my spelling that I’m a Yank) in recent years, seeming loss of mojo, and quite possibly “pulling a Vista” with Win8, have to damage confidence in their entire offering…drumroll please…OS included. The webstack, wild and woolly though it is, has the benefit of being permanently entrenched. Everything else is a proprietary product football that could theoretically be tossed in the garbage, witness WPF. I loved working in WPF, and did so exclusively for 3 years as a mythical Design Integrator. It flew me off to a powerful fantasyland where browser inconsistencies melted away like a bad dream. Actually I got deep enough into XAML that I did run into the differences in rendering on XP vs Win7, but they were the vanishingly small exceptions that proved the rule. 

    At this point I may never work on a new WPF project again, and that will be just fine. I don’t want my technology “owned” by anybody, for then it is vulnerable to their vagrant whims. That’s why I applaud anthony for going the C++ route.

  • Anthony

    Thanks Aaron! I have given much thinking about it and decided to go that root not only for myself but also for the company i work for.

  • Andy Bolstridge

    the thing about javascript is the library support – take a look at the mountain of js libs, many of which produce some excellent results. I was just looking at Raphael.js for some demos, it’s pretty powerful. For LoB apps, typically you will be able to produce HTML5 GUIs with few problems, and great deployability, and as you’d have to code your servers independantly, you get the kind of decoupling that’s always been missing with Windows devs as they use the easy-to-click-to-add-code tools. Performance is going to be the big problem with HTML5 though, but then WPF perf was never great either. Regardless of fast animation, CPU crunching is easy – you offload it to the server which is really easy in web-based apps, no native experience required.

    For desktop apps though, I’d go with Qt as it has a very easy-to-use GUI system that you can extend with QML gadgets to give you the best of both worlds (imagine if you could drop a WPF usercontrol onto a winform… wouldn’t that have been nirvana? That’s what its like with Qt/QML). (and, for coolness, look at Wt which takes your Qt app and draws it using HTML controls instead of GDI for deployment over the web. That’s a fancy idea, though I’m not sure about how well it works in reality)

  • Irked

    This article is abou 2 years late dude

  • anamika

    I assume you are windows developer :). But i am interested on your thoughts on Android Holo UI. I like Metro simplicity, but ICS holo UI is beautiful. We need a mixed breed.

  • SoShaunShrugged

    The conversion to HTML/JS required a 200% increase in staff capacity to offset the loss in productivity caused by switching away from XAML. Watching it unfold was comedic but also a sobering experience — this is the new normal.

  • Had similar experiences. Watched teams switch from WinForms and/or WPF/SL to HTML5 and seen not only a massive increase in staffing but i also saw a lot of dead end development “oops we chose the wrong framework at the start…revert…”