With the rampant explosion of wireless smart phone devices in the marketplace, it should be no surprise that more and more businesses are delving into the mobile world. Whether it’s for productivity gains by arming staff with more ready access to data, or from marketing pressure to remain competitive and become more visible and viable with prospects, or to meet customer trends by appealing to the next generation audience – today’s business applications are going mobile.
Beyond email and messaging services which are already widely used, mobile applications could range anywhere from event registration or other form-based applications, scanning for inventory updates, field worker schedule task lists to shopping cart applications and marketing schemes based on GPS locations and more.
Less than a decade ago, the choices were largely between Palm OS or Windows Mobile, and the primary challenge with wireless business applications involved available bandwidth and network coverage. Data throughput capabilities were, and can still be, more limited, with spotty reception in some remote geographical areas. Today, there are so many more devices that support varying platforms and operating systems (Apple iPhone, RIM Blackberry, Google Android, Windows Mobile, Palm Pre, Symbian, etc), and so much more diversity in application technologies along with faster networks and coverage. With such diverse and ever changing capabilities along with aggressive competition for market share, the business decision of going mobile is no simple matter and constantly evolving.
Let’s build what?
As a business, the key decision will be driven by the application purpose. Is the application type one of a sequence of automating business processes, such as a collection of data, say, to capture in store inventory in order to determine new order volumes? Or is it for issuance and update of work orders for utility field workers? Perhaps the purpose is more about giving customers ready access to buy your products, with a marketing incentive to receive discounts or collect loyalty points by showing a discount barcode at the store POS, or a marketing push based on geographical GPS location identifiers. After all, let’s face it, productivity gains with mobile applications are more about ready access to data for mobile users. For users who have access to a computer all day, using a small handheld device will not be as productive. As with all application design processes, you need to clearly establish the user requirements and business purpose first which will then determine your options for devices and software.
For whom?
Deciding on the application style and device target has to be driven by the intended users – if it’s an internal business application, or even one based on compliance, then the decision can be controlled, but if the users are external then the challenges are greater.
If the users are internal to the business then there can be better or even full control over device selection and controlling the enabling technology. Hospitals providing nursing staff with mobile access to monitoring information about their patients is a perfect example of being able to control what type of device can be used and in so doing determining what application type to use. Even more so would be a wireless scanning application set up for stocktaking within a designated warehouse using designated access points. If the requirement is that the device should also be rugged to enable damage control, then the device selections become even more refined.
If the audience is broad however, then it needs to be figured out how to get the users to come to you, whether this means having the user purposefully go to an apps store to download the application, else having the user subscribe to some messaging service that would accept marketing output, or having the user choose to key in a URL to browse the web application. Consider having your boarding pass available via your phone, or registering for a conference – if the user is a regular flyer, they would likely have loyalty flyer points, and the encouragement to download an application to their phone for the purpose of convenience and ease-of-use would be a relatively easy sell. A conference registration, with say, barcode registration, however would likely be better handled as a web-based application since it would typically be a one-time use. There is likely little hesitation from soccer fans to download the latest FIFA World Cup mobile application that streams live feeds with their teams’ latest results, but that mania does not extend to most businesses.
And then how?
Now the technology approach… Going native (building an application that executes directly on the device OS) or using web-based applications becomes the next major decision that needs to be determined once ‘what’ and ‘for whom’ have been decided. Does the application need to store data (and how much) locally and while offline, or does the dependency to access perpetual live and updated data have more significance? Depending on the application purpose, is the application capturing data, or is there a requirement to have, say, the sales person maintain a list of their customer base in that particular area, or does the foreman need to know the active daily list of work-orders currently scheduled.
In general, browser-based applications provide the benefits of easy deployment, almost no concern regarding the browser type, and hence much less concern about the device used. Native applications provide highly robust features and capabilities and an ability to store as much data as the device can hold, and they’re fast. Platforms and OS with related development tools can be proprietary and dictate the choice of devices used, which often leads to a decision to lock-in to a platform and standardize on devices.
The following shows a quick overview of how the advantages of one are almost the antithesis of the other.
| Native Applications | Web-based mobile applications |
| Pros | Cons |
| Database storage capability | Limitation as to storage of data |
| Typically most responsive UI | Dependent on bandwidth |
| Cons | Pros |
| Typically requires proprietary development language – more complex to learn | Requires web development skills – easier learning curve |
| Cannot be shared across other platforms OS. Need to target custom apps per device | Can be deployed across multiple devices, provided there is a browser |
| Testing and maintenance expands exponentially with more devices and platforms chosen | Testing and maintenance is more controlled due to focus on browser rather than device |
| If the device is lost or stolen, that data is still resident | Data is dynamic and only loaded in real-time |
This comparison is purposely generalized, and one could debate the details of these points ad nauseam. For instance, while all browsers render simple HTML, the extent of AJAX capability differs, and even more so the ability to support Flash and other advanced visual rendering. In essence though, browsers enable easier deployment than native applications, which are very platform specific.
As technology progresses, solutions to diminish the cons listed will mature for both camps. HTML5 and Google Gears are working towards enabling the storage of data locally for web-based applications. 4GL mobile application development templates are becoming more readily available to overcome the hurdle of building native applications. Data wipe techniques that clear the data from devices are evolving to handle security concerns from lost or stolen devices.
Alternatively, hybrid applications that use both web technology and native OS capability can take advantage of both. For example, consider a sales business application that relies on a comprehensive list of product info with today’s pricing. During the course of the day, sales order and return updates need to be dynamically updated to the back-end processing server, in order to commit product allocations, calculate discount price breaks etc. A hybrid application could enable the large volume of product data to be downloaded via connected synchronization, while the web technology would support the dynamic live interaction.
Ready, set, go…
The decision to ‘go mobile’ is made; now let’s factor some further closing necessities.
- Device management: The smaller the devices, the easier they are to be lost or damaged. Security implications need to be factored to handle data being in someone else’s hands.
- Ongoing support for maintenance and testing: Once you commit to mobile applications, you have to commit to ongoing budgets and resources allocation to support constant OS updates and changes.
With budgets typically being constrained, most SMB companies don’t have the luxury of dabbling or building applications that suit all and every device. There are notable large scale software vendors that have created partnerships (in some cases by acquisition, such as SAP acquiring Sybase Unwired) with specific mobile platform vendors, and by so doing have forged a level of certainty and control regarding compatibility and ongoing maintenance. Others, perhaps with specific business pressures, need very large budgets to support and target multiple platforms to try to garner audiences across all devices. That’s a luxury not available to most.
Native applications depend on and benefit from the mobile OS and typically have a large capacity local database. Choosing a platform however typically requires a lock-in or at least a commitment to that platform, along with the ongoing requirement to keep abreast of any version changes to that platform’s OS. Web-based applications definitely score on the no deployment advantage, and network coverage and competitive data plans continue to improve enabling constant access to connected data. The local data storage constraint however is still a limitation not fully resolved.
If this is your first time dabbling in the mobile computing field, then testing the waters with a prototype would be recommended. A web-based application would be the lowest cost and quickest time-to-market to start to become familiar with the nuances and features of these small and sexy devices that are taking the market by storm. Ultimately though, it does come back to the focus on what the business requirement is with its business gain, before choosing the technology.
