HTML5 - Transforming the customer experience for Banks

Yes HTML5 is a big bonus especially as the Ipad is not Flash software friendly. Our OnDemand Sales Application is scheduled for the Ipad this quarter and the sales team have all been promised an Ipad's to track their deals plus show the software while they are with customers, that's all down to HTML5!

Whilst HTML5 has some great benefits it won't be as fast, rich or secure as a native application.  The fact that you can need to install a client to your device means you can store additional information to secure the handset that you just can't do with a browser.  With apps increasing in popularity, and security such an issues for browser it will be interesting what happens over the next few years.

https://www.finextra.com/Community/profile.aspx?memberid=59501 

Some banks already use HTML based mobile banking, look at LloydsTSB for example. There is as much risk in Native Apps as browser (depending on platform also).

In terms of performance there are optimised Javascript engines and techniques for mitigating any concerns.

I'm not saying that HTML5 is ready (because it's not fully supported, and fully cross browser compatible yet) but some of the concerns people are raising are incorrect.

The Lloyds app has been universally acclaimed as one of the worse implementations of a banking app in recent years.  That is the last example you would want to use to proclaim the benefits of HTML5.  Especially considering the effort and timeline it took to deliver.  I believe 18 months from start to finish. 

With a native app you can store unique identifiers that are encrypted on the device, basically creating a one-to-one relationship between that version of the client and that device.  As a hacker I would basically then have to steal the device to access that users content.  With HTML5, or any browser based solution, I just need to phish their details and login in locally.

In terms of speed, having high res images stored as part of the client, instead of downloading them is always going to make the app faster and look richer.  Sure 4G is coming along etc, but for a while native will be the way to go for high-end applications.

As an ex-Lloyds Bank employee I can't comment. ;o) The timescales don't surprise me, but generally they tend to say less about development effort than delivery processes.

A native app would need an initial download of high res images, however a HTML5 image could be cached surely? However given this is for actual banking should it require many such images?

I agree on phishing. But given some of the non iOS app stores lax checking surely you could create a fake app that simply took your online credentials and passed them on?

When we look at some of the social apps using HTML5, like Facebook, you gotta see that many corporate or self service apps don't need a lot of "richness" on mobile, and that is more the point I was making ;o)

Agree with the above comments - thats why our approach is via a device abstraction layer enabling a single native app to be deployed across any mobile device and benefit from the native functionalities, but with an HTML5 presentation wrapper to make the presentation ubiquitous (and can also leverage HTML5 functions too).  Cool (but serious) stuff.

Thats cool, are you using a library for that ?

We have the Streamezzo Workbench and Eclipse based IDE.  It takes the Javascript from Web Apps and using 'InstantScript' (Java) transforms that into the native API call for the device.  The App is packaged up for the target device(s) using the workbench and means that native content/code can be updated silently and online as required (e.g fixes and graphical updates).  Its WAC API compliant.

We call this bridge between HTML5 presentation and native app execution HAWK (HTM App Wrapper frameworK).    Advert over!