In the dying days of the last millennium the buzz in boardrooms of large companies was around achieving a web presence and not getting left behind in the dot com boom. With web presence now mostly established in all but the most technophobic companies, the chatter is mostly around the mobile space.
Just like the early days of the web, the mobile world is a volatile environment and establishing a mobile presence is not as easy as many would have you believe.
For the hobbyist developing apps in their spare time failure just means that you move onto the next idea, but for a large enterprise failure could mean spiralling costs, brand damage or security breaches.
For many companies mobile means just one thing: ‘We need an app!’ Apps are certainly one solution but they are by no means the only one and, in many cases, not even the best solution. The first port of call for anyone developing enterprise applications for the desktop is the browser and the same should be the case for mobile.
With the support for HTML5 by most modern mobile browsers you have the ability to develop rich internet applications that can also interact with many of the capabilities of a mobile device. If, for example, you want to use the device’s GPS sensor to find the current location, use the compass to determine which direction you are facing and then use the camera to capture an image; this can all be done from a browser.
As HTML5 evolves we will see support for more capabilities; for example, support for the near field communication sensor is just around the corner, with other capabilities likely to follow.
Even if the thing you want to do cannot be done in a mobile browser, the first step in your mobile journey should still start with the browser. There are many companies who have mature mobile offerings in the app space, but accessing their website on a mobile device takes you to the desktop-optimised site rather than one optimised for mobile.
As an end user I might get a slightly better user experience from the app but as a company I might have invested a lot of money and resources in an app that could have been more cheaply and easily delivered in a browser. Alongside this, the first mobile experience a user is likely to have with a company is through the browser; if this is poor then how likely is it that the user will download the company’s app?
In order to get the mobile browser experience to an acceptable standard consideration will have to be given to responsive web design. In its simplest form this takes the information received from the browser and rearranges the content to match the screen it is displayed on. It is, however, seldom good enough to simply change the way content is displayed. Consideration has to be given to how the content is interacted with. The mobile site needs to be optimised for touch instead of click.
The starting point for this is to make elements big enough to be touched, but further to this you need to ensure that touch events are triggered appropriately to avoid the delay associated with click events. Often making the same site work equally well on mobile and desktop is a step too far and the easier option is to route mobiles to a separate site where you can give a truly touch-optimised mobile experience.
When considering creating an app the lessons learned from the mobile web user experience and the data collected will contribute to the success of the app. A good mobile optimised website can be used to get end user feedback on features they would like to see and usage analytics on what devices they are using.
This brings us to the main questions that should be asked: what do people want? An obvious use case of mobile is to enable people to interact whilst on the move, so it is important to concentrate on the aspects of your business that lend themselves to a mobile customer.
For example, as a banking customer it is likely that I may want to quickly check my current account balance or transfer money from my savings account on the move, but probably less likely that I want to apply for a new bank account. Alternatively as a banking employee I may want to be able to start a bank account application with a customer on my mobile device in the foyer of the branch and complete it later in the back office.
When you know what you and the end user want the app to do the next problem is choosing the platforms that you want to support. Data from usage analytics of the mobile web will give a pointer to which operating systems and devices are most popular. It is likely that the app will need to be developed for at least two platforms.
When you develop a website that needs to support more than one browser it is likely that there may be tweaks here and there in the code but it is usually nothing very significant.
With an app the story is quite a different one, as it has to be developed separately for each operating system. Recent innovations in developing cross-platform frameworks have meant that it is now possible to share code between apps, but for some types of app code must be written specifically for each platform. Maintaining multiple versions for different operating systems also has a testing overhead.
This is then exacerbated further by the number of devices and the situations in which these devices are used. Testing a web app usually means sitting behind a desk running the app on maybe three or four browsers on a corporate test network. Testing a mobile app should be done in the real-world on real mobile networks on tens of different devices.
For many businesses a mobile app is the first time they actually distribute a piece of software to the general public. Fortunately the various app stores have made the distribution bit relatively easy, but there are several other aspects that need to be considered. With a web page most of the true code is protected on application servers, safe inside the corporate network; an app however has the code on the device itself.
In the worst case scenario code is interpreted at run time so held in plain text but even compiled code can be de-compiled and converted to plain text. This obviously exposes a vulnerability to the corporate network. Obfuscating the code can go some way to protecting the code but can never protect 100 per cent.
Other issues can arise from not being able to control whether a customer upgrades to the new version of the app. A company can always guarantee that, if someone is accessing a website, they are accessing the latest, hopefully bug-free version of the site; this is not the case with an app where the customer could be using an older version of the app containing bugs or even security vulnerabilities.
It is therefore essential that apps are given versions and any access back to the corporate network has the ability to allow or disallow versions of the app. There are many more security vulnerabilities associated with apps, which would merit a textbook on their own.
If nothing else this brief article has hopefully put across the point that going mobile is not just about apps and that going down the app route is not always an easy option. Another point to remember is that unlike some other technologies, the devices and operating systems customers are using today will be obsolete in maybe as little as two years.
So a project to deliver mobile functionality today cannot be thought of as one that ends in maybe three to six months; development of a good mobile application never ends, rather it continuously evolves just as the devices it runs on does.
