Best practices, pitfalls and how to ensure your mobile app succeeds
Mobile development using HTML5 has gone mainstream. It’s not hard to understand the motivations driving many enterprises to embrace HTML5-based mobile apps. The promise of HTML5 is that it solves a number of different problems currently being experienced by enterprises attempting to offer mobile solutions.
First, mobile developers are a scarce resource. The demand currently exceeds the supply, and many of those developers gravitate toward start-ups and other companies that work with leading-edge technology.
Second, the continuing battle for market share in the smartphone space means that most organizations care about supporting at least two, possibly more mobile application platforms. It’s not enough to have an iPhone app; consumers expect an Android version of the app, and possibly a BlackBerry version as well. Developing native apps on these platforms allows for very little in the way of code reuse – the platforms are too different. As a result, supporting multiple platforms can often mean three times the application development cost.
In the IT world, there is considerable debate about the merits of HTML5 versus native app development. This paper is not intended to advocate for one approach over another, as we believe both approaches have their merits. Rather, the thesis of this paper is as follows: if you plan to build an HTML5 mobile app, you should view it as very different from a traditional web application.
Like “Web 2.0”, the term “HTML5” is as much a marketing term as a description of a technology. Speaking as narrowly as possible, HTML5 refers to the latest edition of the HTML standard, which includes some considerations for HTML rendering on mobile devices.
Although it’s possible to create an HTML5 mobile application from scratch, in truth, few people do this. The majority of HTML5 mobile apps are created using one or more mobile development frameworks. Here are some of the most common ones:
uncommon) CSS-like styling language called SASS.
PhoneGap’s focus is different than jQuery Mobile and Sencha Touch. It provides a container in which HTML5 assets can reside. While it can be used in many different ways, it’s ideal for apps that are wholly contained on the device. It is not uncommon to combine PhoneGap with one of the other mobile frameworks, since PhoneGap provides the container, and the other framework provides the controls and/or themes.
Similar to jQueryMobile being a JQuery extension that emulates mobile UI components, Dojo Mobile is a Dojo extension that emulates mobile UI components.
A Case Study
Recently, Intelliware worked with a financial services client. The client had previously engaged a development partner to build new functions on their existing mobile banking app. Unlike the existing functions, the new features were to be developed using HTML5 with content served up from a .NET web infrastructure.
HTML5 Development Considerations
Let’s consider a few examples of typical technical design considerations. Each of these examples attempts to show that the patterns and ideas that are considered acceptable for browser-based web applications can lead to mobile applications that are slow, unstable, or which download and transmit in a way that yields a sub-optimal user experience.
Understanding how jQuery transitions work is a good way to understand why building HTML5 mobile applications are more complex than traditional web applications. The first thing to understand is that jQuery-Mobile uses custom attributes on HTML documents to indicate what parts of the document can be considered a “page”.
Consider the following example:
<html> <body> <div id=”page1” data-role=”page”> ... </div> <div id=”page2” data-role=”page”> ... </div> </body> </html>
jQuery-Mobile will process this HTML document by rendering “page1” on the device. “page2” will remain hidden. A transition between those two pages can be easily implemented by, for example, clicking on an anchor such as this:
<a data-role=”button” data-transition=”slide” href=”#page2”>Next</a>
Transitions between pages in different documents, on the other hand, become slightly more complicated. The slide effect – popularized by the iPhone – is very different than the traditional HTML transition behaviour when two different documents are concerned. And yet, it is precisely this kind of “native-like feel” on which users will judge the acceptability of the transitions. Under normal circumstances, standard browsers transition from one HTML document to another HTML document by clearing the screen and loading the new document. Most mobile HTML5 apps want to avoid this kind of transition, because it broadcasts to the user that the application is web application-like rather than a mobile application-like.
So, to support native-like transitions between separate HTML documents, jQuery-Mobile intercepts the anchor click and fetches the new document asynchronously using Ajax. Once the new document has been downloaded, the jQuery-Mobile framework scans the new document, finds the appropriate “data-role=’page’” item and appends that item to the current document’s DOM model. Once that’s completed, a CSS animation can be used to enable a slide or popup (or other) transition between one “page” and another, as above.
This is a powerful feature of jQuery-Mobile. jQuery-Mobile makes it easy for developers to create native-like transitions from one HTML document to another. The example used above, relates to simple clicking from one page to the next. But the topic extends to many types of page navigation, including FORM entry and POSTing: not only should the POST-redirect-GET patterns be eschewed, anything that causes a full-page reload should be avoided.
Some of the consequences of the power of JQM transitions, however, warrant discussion. The first, most important consequence relates to the management of resources.
The crux of this issue is this: the behaviours and practices that typical developers employ to build standard web applications are not good enough to build HTML5 mobile applications. To do this right, you need better-than-average skill with the HTML5 toolset.
Up In the Air
One of the examples that we find ourselves frequently citing is the example of the HTML5 web application operating in an airport. Imagine this situation: I have a mobile app that serves up HTML5 content from the app-provider’s web servers. If I launch this app immediately after connecting to the airport wifi, my app’s request for the first HTML screen will be redirected to a page hosted by the airport wifi provider asking me to accept their terms and conditions for using Internet access. After confirming, I’m redirected to an airport home page.
When this kind of situation happens in a browser, I have access to the browser URL bar, and I can call up a different URL. But when this happens in a server-based HTML5 mobile app, the user usually has no control over navigation and can’t get back to the app’s functionality. This is a painfully common circumstance, and yet most HTML5 mobile apps get tripped up on it.
Web sites that are visited by millions of users every day are heavily tuned for performance. But for many sites on the web, performance can be considered “good enough” without much work.
The web hasn’t always been like this. In the earliest days of the Internet, web designers were expected to track a lot of information about how to optimize each page for web display.
In his presentation, “Going Fast on the Mobile Web”, Jason Grigsby argues that we’ve left optimization behind, and instead have become gluttons for bandwidth. Because of increases in download speeds and processing power, the early fastidiousness about site optimization has become a lost art. He argues that the average modern web page is now 20 times the size of the average web page of 1995.
That being said, mobile developers working on HTML5 applications that serve up content from the web cannot afford to be slapdash about performance optimization.
Now, it’s not like the art of website performance is esoteric. As mentioned earlier, the most popular websites need to focus on performance optimization in order to satisfy millions of requests per day. Grigsby points to Yahoo’s key performance tuning recommendations.
Some of Yahoo’s recommendations are more applicable to mobile than others, but a good mobile HTML5 developer needs to be fluent with these optimization techniques, and needs to consider many of those techniques as the application is being developed.
From the list of 35 techniques Grigsby advocates, there are eight key recommendations for mobile developers:
- Turn on GzipCompression
- Fewer files
- Aggressively encourage caching
- Minimize file sizes
- Simple, valid markup
- Reduce DNS lookups
- Avoid redirects
- Limit cookies
Applications with a non-trivial native shell can additionally serve up certain assets directly from the app. Mobile application developers need to be able to speak about each of these optimization strategies fluently.
In many ways, scrolling can be seen as a specific sub-category of performance, but it’s an especially crucial behaviour to talk about because users’ expectations of a native-like experience really come to the fore in scrolling. In many ways, scrolling is the behaviour that makes or breaks a user’s acceptance of your application as an acceptable mobile experience.
There are a number of “scrolling libraries” available on the web – scrollability, touch-scroll, iscroll and iscroll-lite among others. The essential function these libraries offer is an easy ability to construct HTML5 pages that have the three common “regions” of most mobile screens: a fixed header, an optional fixed footer and a scrollable “middle area.” (The importance of these libraries may lessen as the need to support iOS 3 and 4 disappears).
But “easy ability to construct” is clearly a relative notion. Returning to our case study, we were engaged by our client to work with their original development partner. That partner had already chosen a scrolling library – touch-scroll. When we came on board, the application was plagued by numerous scrolling bugs: the scroll area wouldn’t scroll; its height wouldn’t change as new content was added to the middle area. Again, this was an example of a development team with only average skills being unable to create a good mobile user experience.
Even after we fixed the scrolling bugs, the scrolling experience wasn’t completely acceptable to the client: the feel of the aggressive “flick” that causes a rapid scroll wasn’t sufficiently native-like. So we spent time having a bake-off of a number of different libraries before settling on iscroll-lite. One last scrolling concern required us to really understand the way that jQM events interacted with controls as rows whizzed by the screen.
About the Author
BC Holmes is an IT architect at Intelliware Development with 20 years of experience designing and building applications, often working with new technology trends. She was the architect and technical lead for the team that implemented the first web banking application in Canada, and now she works on multiple mobile applications for banking clients. She has worked in the IT Services industry and the financial services industry, and often specializes in e-Health and HL7-enabled applications. BC has spoken at many conferences and user groups. She holds a Joint Honours in Pure Mathematics and Theatre Arts.
About Intelliware Development Inc.
Intelliware is a custom software, mobile solutions and product development company headquartered in Toronto, Canada. Intelliware is a leader in Agile software development practices which ensure the delivery of timely, high quality solutions for clients. Intelliware is engaged as a technical partner by a wide range of local, national and global organizations in sectors that span Financial Services, e-Health, ICT, Retail, Manufacturing, and Government. Intelliware placed among the Top 5 Mobile Technologies Companies in the 2012 Branham300 report, the definitive listing of Canada’s Information and Communication Technology (ICT) industry leaders, as ranked by revenues. For more information, visit www.intelliware.com.