While doing some more reading and research trying to
determine the subject for this article (continuing from Part One of the series), I decided to elaborate on some factors
I found leaning towards pro-native. This is
not to say that I think they are wrong, or I am right but merely to offer an
outlook that was possibly overlooked. Firstly, an argument of “if it needs no
internet connection it should always be developed as a native app”.
The issue of internet connection or not is an issue of
distribution, and the method by which apps are installed and updated. Coming back to the subject of local storage
(covered in Part 1) there is no reason to rule out a HTML5/CSS/JavaScript
application for a pure offline application. There are a number of HTML5 browser
games now that allows offline play. The use of local storage to store user data
such as save states or appcache for assets and offers the same kind of
functionality that would be available through a native app. Again the
limitation is that most mobile markets do not allow for apps that are not
natively developed. This is where the issue of cross compatibility comes in; the
potential of web/browser applications is limited only by the self-serving
restrictions imposed of the respective markets. Not only can the user data be
stored you can cache most of, if not all the application data through the
browser thus rendering the “offline == native” argument redundant.
Any application whether it is a native or web app will
initially need downloading from the relevant website or the specific device
market. In the case of said web app you can cache all downloaded components in
the browser offering true offline capabilities and likely a much smaller first
download than a native application will need due to the small amount of data in
HTML/CSS/JavaScript files (especially when you consider minified files).
Whether native or web technologies they are merely presentational, it is about
the approach that suits the application. This issue of ‘installations’, ‘clean
end to end experience’, ‘browser support’ are all concerns that have existing
or rapidly developing solutions when you look at applications developed using web technologies.
Installations as it is, I think people overlook installation
via caching using the Application Cache interface or AppCache as it is otherwise
known. This provides many benefits, albeit providing some functionality that is
an unfamiliar experience for the user however with the push to cloud
technologies and the impact the web is having on people’s everyday lives it is
something a user will adjust to. AppCache also provides a seamless, transparent
update to the application which is a benefit to the user in a number of ways.
First, the speed is increased as cached resources are local thus removing the
need to make server requests for assets, this has a noticeable issue in
performance speed for the user. The only exception to this is a download of
resources from the server that have changed but again, this only benefits the
user as it seamlessly updates the application without the user being prompted
or distracted by notifications. Eric Bidleman has a great article explaining
AppCache in more depth. [1]
Installations are
a short sighted concept and installation via caching and transparent upgrades
are often overlooked even though the single feature has been credited as the
main success behind the Google Chrome browser. Using the AppCache interface,
which provides a transparent updates and seamless updates to the application,
can benefit to the user in a number of ways. First, the speed is increased as
cached resources are local thus removing the need to make server requests for
assets, providing a noticeable issue in performance speed for the user. The
occasion where performance may be an issue is when downloading newer versions
of changed resources from the server, but again, this only benefits the user as
it seamlessly updates the application without the user being prompted or
distracted by notifications. The only major downside would be user confusion
over the new, improved, and transparent installation/upgrade procedure as the
rapid change in analogy may affect the experience of users whose expectations
lie with the existing monotony of the “next, next, finish” interface and are
off put by its absence.
It is not ‘installed’ but still perfectly functional
offline, with the ability to get updates over an internet connection (as any
native app would). The advantage of web technologies is the ability to use the
flexibility offered by mark-up/presentation along with a number of robust,
efficient libraries and API’s available. I think it is a case of people not
trusting the nature of the connection, the user likes the trust offered on app
markets – and the way that you install applications is irrelevant, it just
needs a clear analogy. There are a number of other concerns when you consider
the approach to take with mobile applications such as browser support with
things such as CSS compliance and JavaScript engines, but the same argument
applies when you consider developing apps across multiple devices. The overall
cost of developing an application across multiple browsers is far less than
employing more developers to deploy apps for iOS and Android etc. especially
when you consider the financial cost of targeting both. Both use different
native languages, both need separate IDE’s and one even requires a particular
set of hardware and operating system. All major factors to consider when
weighing up the business side of things with the technical.
References:
No comments:
Post a Comment