Wednesday 27 June 2012

HTML5: The end of native apps

The future of web programming is moving towards a common, cross-platform language with HTML5. But will software developers meet CIO demands for new web technologies?
HTML5 is an emerging standard for developing cross-platform web and mobile apps. Many IT chiefs favour web and mobile applications using HTML5 and developers are under pressure to build up-to-date apps using the latest cross-platform web technologies.
How should developers use HTML5 and balance the pros and cons of using emerging web technologies? Is it time to cast off the shackles of native apps for good?
Dan Zambonini, co-founder of web app company Apparus and author of A Practical Guide to Web App Success, says CIOs can no longer count on known timeframes, budgets or even features as a rapidly evolving environment demands project managers exercise greater flexibility.
Zambonini believes back-end software, such as databases MongoDB, CouchDB and ZeroMQ are helping to make app platforms more generalised and less supplier-specific.
Iterative development for web app success
An iterative process relies on our ability to successfully focus on something for a short period of time and takes into account our inability to accurately visualise and predict how theory becomes reality. By taking short, iterative steps, we can focus on creating brilliance one move at a time, and can evolve our app as we get a better feel for the features that succeed and those that don’t turn out as we hoped.
The iterative process happens on two levels. At the higher level, new app features are developed incrementally. For each release these approximate stages are followed: some research, then interface design, coding, a working release and marketing. Check the customer reactions, learn and repeat.
On the lower level, each of the stages is a mini set of iterations in itself, punctuated by testing that informs us whether or not further cycles are required. This holds especially true at the interface and development stages, where a skeleton design or chunk of code can gradually be refined with more detail as it undergoes testing.
If your app development project has a deadline (and unless you’re working on an informal side project, it will), each high-level iteration should be allotted a specific number of days, to ensure a number of full iterations and the learning that comes from them, over the lifetime of the project.
Each iteration should last a fixed length of time, so that your team can develop a rhythm; you will quickly adapt to the recurring deadlines and become adept at estimating how much functionality can be produced in each.
The exact length of an iteration can range from a week to a month. Your team will need to decide on the best length for them based on a number of factors:
  • The complexity of the app: An iteration needs to be long enough for a team to sometimes produce fairly advanced features. Even if these are only developed to a minimum quality or prototype level, they may take weeks.  Similarly, an iteration should not be so short that most of it is spent on planning, testing and deployment, with little time for the actual development.
  • Customer expectations: If you’re developing an app for a client, they may influence how often they expect to see movement and change. This is not necessarily a negative factor if the customer can participate more easily in shaping the development of the application to meet their expectations.
  • Team pressure and rhythm: A deadline needs to positively pressure the team into productivity without being unrealistic and causing the team to opt out of the process. To decide on the deliverables for an iteration, a risk-driven approach is superior to choosing the low-hanging, easy features first.
When taking this approach, you should first develop the high-priority/high-risk features followed by high-priority/low-risk and, finally, low-priority/low-risk. Low-priority/high-risk features should be avoided altogether until the app is a proven success.
Extract from A Practical Guide to Web App Success by Dan Zambonini, published by Five Simple Steps.
“Technologies like these really help developers to embrace change, knowing that project managers don’t have to re-write a lot of code or create complex database migration scripts just to change or add a few fields,” says Zambonini.
“On the front end there are lots of useful frameworks such as dynamic stylesheet Less and Blueprint that help new apps get a first iteration up and running more quickly, so you can collect those invaluable first few pieces of user feedback as soon as possible,” he says.
Zambonini believes the real technologies driving change on the web are browsers.
“Since the start of 2012, we’ve just reached a point where the major browsers are now auto-updating, which is a huge boon for app developers and should give organisations the confidence to use HTML5, CSS3 and Javascript features,” he says.
A survey by Evans Data of 1,200 developers showed 75% are using HTML5 for app development. Furthermore, HTML5 was 20% higher on average than Microsoft’s Silverlight or Adobe’s Flash in importance to the development cycle.
Some firms, such as Royal Bank of Scotland (RBS) and the Financial Times (FT), have started using HTML5 web apps rather than creating native, platform-specific apps.
In April this year, the FT’s HTML5 web app reached two million users after launching in June 2011. The media group has since dropped its native iPad app.
Steve Pinches, FT group product head for emerging technologies, says the app eliminates problems with creating multi-platform native apps by speeding up the development process and reducing costs for developing multiple native apps.
Pinches says: “We believe that, in many cases, native apps are simply a bridging solution while web technologies catch up and are able to provide the rich user experience demanded on new platforms.
“As these improve we expect to see more HTML5 apps and fewer native apps, but there is always likely to be a market for native apps for specific brands or when deeper integration with the hardware or super fast performance are required,” he adds.
While web app development allows preferred tools, which are not specific to a supplier, to be used, challenges remain.
Pinches says tools and documentation are lacking for mobile-based web app development. The HTML5 webkit browser uses a device’s graphics hardware to improve graphics and video display. However, this causes issues such as screen flickering.
But organisations are using HTML5 for mobile apps despite the remaining challenges.
Cardiff University deployed a cross-platform HTML5 mobile app in September 2011 to accompany its native iPhone app, which provides information and services for students.
Eileen Brandreth, director of university IT at Cardiff University, says: “The Cardiff University app is a great way to widen access to some of the university’s key information, tools and services at a time when growth in smartphone use is increasing rapidly in the university community.”
Developers at digital agency, Box UK, used jQuery Mobile framework to develop the university’s app.
Gavin Davies, principal software developer at Box UK, says: “The final specification of HTML5 is unlikely to be set in stone until at least 2014, but we’re already seeing a number of benefits, including powerful audio and video support, useful client-side storage capabilities and highly advanced accessibility. As an open format interoperable between mobile and web, there’s also less reliance on closed source proprietary plug-ins.
“A significant saving can be made in developer time to implement many features; while proprietary technologies like Silverlight or Flash require obscure, baroque tags or fancy JavaScript plug-ins for media elements such as video, HTML5 enables it to be added in the mark-up just like any other standard elements, while retaining semantic meaning.”
Legacy limitations
However, Davies believes corporate organisations are more limited, as they tend to have older versions of Internet Explorer installed, which have poor support for HTML5.
“This means that inelegant work-arounds are sometimes required to provide features,” he says.
Research firm Forrester recommends using HTML5test.com, Modernizr and the HTML5 boilerplate to target differences in browser support and identify cross-platform features.
Forrester also believes native apps are still preferable in the face of such restrictions.
“Gaps in hardware acceleration, inconsistent support for on-device instruments, and incomplete user interface control frameworks still make creating the most engaging device-centric apps a bridge too far for HTML5 at this point.
“That will change over time, but for the foreseeable future, we still see a place in the app internet for native apps and middleware tools that cross-compile to device-optimised code,” writes Forrester in a report titled Embracing The Open Web: Web Technologies You Need To Engage Your Customers, And Much More.
“We all need to work together to stress the web as a platform and to push over the few remaining hurdles”
Despite its limitations, industry leaders see HTML5 as a common language with the potential to completely overcome native operating system (OS) restrictions.
In a keynote speech at the International CTIA Wireless Association 2012 conference in New Orleans, Gary Kovacs, CEO of Mozilla, called for the mobile ecosystem to stop developing proprietary platforms.
He says: “We need to move beyond the silos of native operating systems and hybrid apps on proprietary platforms to device-agnostic platforms that run the full, standards-compliant and open web.
“We all need to work together to stress the web as a platform, to push over a few remaining hurdles like graphics and video and native device API access and work together on the common language, HTML5.”
Users demand that software developers think about how the next generation of apps will transcend differences between OS platforms and browsers, to create a seamless and responsive experience.
Whether that happens with HTML5 or a future technology that does it better, the development process will need to be flexible to cater for new and emerging technologies - and the common language industry leaders are pushing for.

No comments:

Post a Comment

Note: only a member of this blog may post a comment.