Digital Product Innovation

Over the past week I’ve been writing my thoughts and opinions on why HTML5 is not perfect, but good enough for the needs of most Enterprise applications.

Medium to large Enterprises are currently only at the point of being interested in mobilising their internal IT systems, and they are not yet at the point of committing time and money to think through what they need to mobilise their workforces. My expectation is that most organisations will make-do, only improving the mobile capabilities of their workforce as updates and new releases come from their traditional IT vendors.

These updates and new releases will use a mixture of good and bad mobile design, and little in the way of User Interfaces re-imagined for mobile. Really speaking, this is no improvement over where these IT-led organisations have always been with their systems on desktop computers (and before that on computer terminals).  Thinking about process re-engineering, User centric design and visual or creative design are not things that many companies are comfortable to address, and this problem will be exacerbated when the  job  of mobilising the organisation lands in the lap of the IT department.

In addition, there will be a small group of companies that either start from scratch as mobile-native operations, or have the vision, time and resources to rethink how their business could be revolutionised by embracing mobility. These guys are the ones who are going to be successful through, and because of their mobility strategy.

And, this is where HTML5 comes in. It’s not fantastic for creating engaging and visual interfaces on mobile, but it is very good for creating User Interfaces for form-filling and simple data entry (the bulk of business process rethinking currently appears to be about paper-form replacement), and, the skill sets needed to build and support HTML5 are 1) readily available, 2) mostly the same across many devices, and are therefore 3) cheaper to employ.

HTML5 will win the day not because of any of its features, but ultimately because it is the easy, non threatening, cheap option.

Here’s a recap of the points I’ve made previously :

Just enough is good-enough for Enterprise mobility

First two in a series of HTML5 expectations

3 and 4 in a series on HTML5 for the enterprise

Assumptions 5 & 6 in the series on HTML5 for Enterprise

The story continues – HTML5 and what it is mostly likely good for in Enterprise.

5 – An HTML5 web app can do everything a native app can

Native apps give ultimate access to the features of a given device.

For example Android allows the developer to pretty much do what they like – even going as far as overriding the built-in phone dialler app if that is really whats wanted. Android does suffer from some fragmentation of the operating system though – either because the user is not using the most recent version of the OS, or because the device manufacturer has changed the base Android software – so some things don’t always work on every device.

iOS is quite a bit more restricted both in terms of the device features that are made visible to the developer, and in terms of the functionality that Apple’s vetting process will and won’t allow.

In contrast, HTML5 does not offer the developer access to all of the native device features. The browser on the device is somewhat abstracted from the underlying hardware and so while HTML5 does offer access to some functions which were traditionally only available to native apps – the camera for example – there are some things which it doesn’t do, or doesn’t do particularly well.

Anything that requires intensive computation within an HTML5 web page – such as complex animation, or even page transitions – can often appear stilted or unresponsive on a mobile device. Coding these compute-intensive tasks inside the browser is all achieved through Javascript, which is traditionally not considered a high performance language (though this does have a lot of attention so it continues to improve rapidly). Native apps – coded in Java for Android or Objective C for iOS – don’t suffer from these same performance limitations, and can access a multitude of third-party libraries to assist with complex tasks.

Last on this point, a note on some of the UI frameworks that are around right now, such as the well known JQuery mobile and Sencha, and the lesser known such as Kendo, Lungo (in development, but my favourite looking),

6 – Hybrid apps will solve HTML5’s deficiencies

There is a middle ground between Native apps and HTML5 web apps, known as “Hybrid” apps. There are several of these available, but from what I know these all work in a similar way … a native app which offers access to underlying device features through an API which is common to all devices, and a User Interface built in HTML/Javascript/CSS.

Hybrid apps have a few immediate benefits :

• Your hybrid app is installed onto the device in the same way as any other native app – downloaded from a website or Apple iTunes/Google Play.
• The hybrid app containers offer the same access to native device features across all devices and operating systems
• Most coding for an app uses HTML5/Javascript/CSS3 so the skills are relatively available, and are cheaper, compared to Objective-C or Java

With a few drawbacks, of course :

• HTML5 User Interface may use a different browser (or web view) than the standard browser on the device, leading to more inconsistencies regarding HTML5 and Javascript support.
• Some Hybrid technologies require the developer to ‘tool-up’ for each platform so that they can build and deploy the hybrid app to the app store. This would include using a Mac for any iOS development (which may seem like a small thing, but not every dev. shop use Mac’s). Note that there are Hybrid technologies around such as Trigger.io, Phonegap, and maybe others – which offer a service to build your app in the cloud, removing the need to tool-up for each device platform. Trigger.io is a personal favourite of mine due to it’s easy to use web based toolset vs. Eclipse IDE.
• In an attempt to provide generic support across platforms, not all Hybrid containers respect the uniqueness of all devices’ User Interface. The UI can look generic, meaning that at least in theory your users are not going to like it. In practice this may not be that big a deal. It is worth checking though that all the devices physical keys work in the expected way – e.g. as iOS don’t have a physical “back” key it may be missing or not work on a Hybrid app running on Android.

More to come in conclusion on why only some of the above points and preceding posts are relevant to Enterprises.

Continuing the story on HTML5 and why it’s ‘good enough’ for enterprise, here are two more commonly heard assumptions regarding building a web app using HTML5.

The current HTML5 ecosystem is by no means perfect, but it is very good for some things. The current draw backs in user experience and browser and device ubiquity probably just don’t matter for Enterprises, who are for the most part IT driven and uncomfortable thinking about visual design and User Experience as part of a system design.

3 – HTML5 development is cheap – ’cause it’s the web, right ?

There’s no doubt that the design and development skills needed to build HTML (and the absolutely necessary Javascript and CSS) are readily available, and the development tools are mature and sophisticated. However, my own experience has been that :

• Because HTML5 is an evolution from HTML4 and other associated technologies, it is fairly easy for any web designer or developer to claim some HTML5 skills.  While HTML5 is not a hugh leap from HTML4 or XHTML, it does have nuances and a very heavy reliance on CSS3 and Javascript.
• CSS3 skills can be in something of a no-mans-land between visual design and development. A good all rounder web generalist is more likely to be comfortable with CSS3 than a dedicated designer or dev.
• Javascript is becoming more and more arcane as a plethora of frameworks and add-on libraries and languages sprout up, in an attempt to rationalise and simplify the use of the language which is now expected to be enterprise-grade. In fact these are having the effect of making the development ecosystem more and more complex.

Add to this that few people are really familiar with Responsive Design (so it has to be learnt), + time overheads to cater for the vagaries of each browser and device, and suddenly things are not looking quite so cheap and straightforward.

4 – Developers will desert native apps in favour of HTML5 (because it’s cool)

Development using native technologies for iOS and Android have become a huge success story for Apple and Google and also for the developers who actually build the applications that fill iTunes and Google Play. While Apple and Google take 30% of the sale of any application (for providing a consumer billing platform and app store as a distribution point to the market), the remaining 70% goes into the pocket of the developer. Build a successful app and you could be rich.

The fact that there is money to be made from native apps development is something that the HTML5 lobby continually ignore – vaguely hoping that because HTML5 is a new, cool, thing developers will realise its the future and just slowly move across to it as demand from consumers increases.

Unfortunately, there are some things that will need to be in place before there is an easy way for a developer to charge for their work and an easy way to be found by potential customers. Some native devs are indeed now saying that it is getting difficult to be found in the iTunes app store and Google Play due to overcrowding – but where would they rather be ? Out on the web trying to drive traffic to their web-app with SEO and charging customers via Paypal … ? I’m not so sure.

More to come soon.

The first couple of expectations and assumptions regarding HTML5. Please let me have your comments and see whether these ring true …

1 – HTML5 works the same in all browsers

HTML5 is not yet a ratified W3C standard, however each of the major browsers already have support for the bulk of HTML5’s features. There are plenty of compatibility matrixes available if you need to find out what works where (here’s one at Wikipedia), so I’m not going to worry about that here. However HTML5 compatibility only describes (approximately) one third of the whole picture of what needs to be built. Javascript and CSS3 are the two other cornerstones of the technologies needed to build a modern web interface*, and both of these have their own varying levels of support in the major browsers, complicating things further. So, if you want to build one web site that works in several browsers, there are two possible approaches :

1. Cut the features of the web site to a bare minimum so that what you build uses only the generally supported features of HTML5/Javascript/CSS3 that work in all browsers. This will result in something that looks very generic/plain/old-fashioned (take your pick) but will probably do the job from a functional point of view.
2. Plan to allow your designers and developers an extra 10%-15% for every additional browser that you add to the list to be supported. They will spend this time working around different features and variations in the HTML5/Javascript/CSS3 support for each browser.

Alternatively if cross-browser support is less important you could target a single browser, or choose a couple which are widely used across your target user base. Chrome and Firefox might be the two, Opera could be a consideration, Safari if you have Mac users, while Internet Explorer – in any incarnation  still considered something of an outsider – will probably pickup with the spread of Windows 8 and IE 10.

There’s a great score card for all browsers here, showing that Maxthon 4 is the winner in the HTML5 stakes right now (and I’ve got to admit I’ve never heard of it)

*There are several other lesser-used technologies included and referenced by HTML5, such as SVG, MathML, Ruby …

2 – HTML5 works the same on all devices

A common statement from a client who is looking to build an app or web-app is

“We only want to build one thing, and we want it to work the same on everything”

This question is driven from the clients (usually anecdotal) understanding that native apps need to be written explicitly for a given single device, and the following expectation that simply building it in HTML(5) will magically make it work on everything, everywhere.

If you think about it for a moment, it’s actually a big ask for a web page (and all of its embedded media and images) that are designed for a 15″ screen to shrink down to a 2.5″ screen, and every other screen size in between, without some serious considerations about the effect on the usability and features per device, not to mention the fact that the smartphone user almost definitely wants different things from a website when they are walking around town vs. in front of their laptop in the office, and would want a different experience again on their web TV.

A simple way to think about this usability difference per-device is to consider ‘hover’; A common bit of design fluff is that some parts of a web page change when you hover your mouse pointer over them – maybe the colour changes or something animates …

Now think about how hover works on a tablet – that’s right, there’s no mouse pointer and no hovering – when your finger is not on the screen, the browser doesn’t know where it is – therefore your designers and developers need to cater for this when building the web app. Either they don’t use ‘hover’ at all for any device, or you design and code to cater for the devices where the concept of ‘hover’ exists, and those where it doesn’t.

The current answer to the most obvious of device differences – screen size – is known as Responsive Design, which is a way of scaling a given page up and down so it is fit for the size of the screen on the device. Responsive Design is a great idea, and can work really well, but it involves a lot of complex design decisions (per device-size) up-front, followed by a highly complex HTML5/Javascript/CSS3 coding exercise. Of course, frameworks and tools are springing up to meet this complexity, but be prepared for 5x effort when building for responsive design vs. a single device and browser.

More to come on this topic over the next few days.

Over the next few days I’ll be writing about HTML5 – what it is, and is not, and why some of the issues it faces are irrelevant for Business and Enterprise.

HTML5 has a lot riding on its shoulders, and there are many misconceptions about what it can and cannot do, and why you’d choose to use it as a technology. There are many things that, as of this writing, just don’t completely work. For the most part, these flaws are well known and will probably be fixed in time by the various browsers but there are other problems of expectation that are not really technology problems, so won’t be fixed as such.

The common expectations are that :

1. HTML5 works the same in all browsers
2. HTML5 works the same on all devices
3. HTML5 development is cheap – ’cause it’s the web, right ?
4. An HTML5 web app can do everything a native app can
5. Instant updates are better than software upgrades
6. Developers will eventually flock to HTML5, leaving native apps behind
7. Hybrid apps will solve HTML5’s deficiencies

What I’ll be attempting to explain in the posts to follow :

• The ins-and-outs of these expectations
• Why none of the above actually matter for an Enterprise application
• What does matter for an Enterprise considering a mobile application

First post in this series, addressing points 1 and 2 is now available