We live in a world where an online presence is quite simply a necessity for any business to succeed. As technology advances, and mobile usage increases, this online presence is not satisfactory if accessible only on the typical PC through a Web browser. Mobile access is becoming just as important as PC access was not long ago, before smartphones and tablets even existed. Moving your company forward into this new world can be an incredibly difficult decision, based on a wide array of technological choices that you may or may not have any experience with. To justify a decision to go mobile, how to go mobile, and how to ensure the ROI is sound, education in mobile technology is necessary.
This discussion attempts to break down the process of developing a mobile strategy into easy to digest topics, written so that the layman can feel they have a solid enough understanding to build a mobile strategy and present a well informed argument for their choices. Whether this mobile strategy is being created for the local dry cleaner or a Fortune 500 enterprise, the following information will provide a useful tool to for moving forward with your strategy.
The mobile Internet has the capability to release a significant amount of added value. As companies strive to capture this value, reach new customers, and retain their current customer base, it is important that a good mobile strategy is developed. Whether this strategy is as simple as creating a responsive web design provide a better experience for mobile browser users, or it requires a complex application be developed for each device type, many factors must be taken into consideration to assure the strategy is a successful one.
The explosion in smart mobile devices in increasing demand for mobile-enabled content and services. Building a mobile strategy can, and should be a complex process with analysis of many factors. Some of these factors have strong ties to the typical business decisions of the past, including time and cost concerns, as well as marketing and monetization of the product. In the realm of mobile applications, the infancy of the technology can provide a new set of considerations that many businesses have yet to experience. This can prove to be a dangerous prospect if not properly understood and analyzed prior to a decision on mobile strategy. Much more, a new breed of salesman, talking tech that is commonly misunderstood, and often overpriced, can easily sway an inexperienced decision maker into moving on a poor solution. I have experienced this first hand in a top Fortune 200 company, where a simple mobile solution, which would have taken an in-house team of three less than 2 months to produce, was outsourced to a mobile agency for over a quarter-million-dollar price-tag. Not surprisingly, this company was missing deadlines within the first month of development, and the in-house team was called on to assist in research and development of the product. Moreover, a more in-depth analysis of the company needs most likely would have found that this simple solution was not the proper path for a successful implementation of a new mobile presence.
Being that the topic of mobile application development is fairly new, and is also changing daily, in an attempt to put together a framework for building a mobile strategy, it is important that the majority of research done is recent. As sources are filtered through, any findings that deal with technology, statistics or processes that are quickly changing, sources older than 2010 will not be considered. For terminology or more consistent relevant factors, older sources may be considered, as well as sources used to provide a historical context.
Information from the Pew Research Center will provide a majority of the statistical data when analyzing mobile usage, as well as app usage within that segment. Their general nonpartisan stance and public opinion polling methods should provide a solid foundation of facts to build upon. Because of the wide variety of businesses that may need a mobile strategy, to include the largest segment, a strong understanding of usage must be provided in such a way that target markets can be compared against the statistical data. With this thorough analysis, business decision makers will have a better understanding of how to use this data to their own benefit.
Research conducted will cover a variety of topics to provide the best overview of the mobile app landscape. At the highest level, the research is used to build an understanding so that the decision of whether to create a mobile strategy for a web application, a native application, or a hybrid approach can be made. Based on this context, factors included in the research will include differences in user interface, user experience, development practices, time concerns, cost concerns, application delivery, application versioning, monetization, security and privacy, application capabilities, and future proofing.
Who Should Read This?
Everyone in a decision-making role in a business, whether small or large, can benefit from reading this paper. The shape of business is always changing, and the introduction of the mobile device, specifically smartphones and tablets, has introduced a very complex web of technological decisions for business owners as they move their online presence forward. No matter what their target market, a business owner can count on the fact that a large segment of that market is using mobile devices, and that usage includes browsing the Internet and using applications.
A recent study done by the Pew Research Center found that, on the eve of Apple’s unveiling of the iPhone 5, 45% of American adults, and 66% of Americans ages 18-29 now own smartphones (Anderson, 2012). Tablet usage is behind smartphones, but is also increasing at surprising rates; a clear sign of how far tablets have come is in another statistic: by 2013, the total number of tablets shipped – 100 million in just the U.S. – almost will be on par with the number of smartphones shipped this year, 108 million. These numbers also jump drastically as income levels rise, but whatever the numbers, it is a guarantee that the way in which people are getting their information is quickly changing. One can only guess how popular these devices will be in the future, but if companies like Microsoft are willing to jump into the hardware market to get a piece of the action, it is easy to conclude that we are still in the infancy of the mobile device era. A surprising show of the increase in not only who has these devices, but also how they are using them comes from eBay. Last year, eBay reported an increase in global mobile sales from $600 million in 2009 to $2 billion in 2010. Trends are up, expectations are up, demand is up, and so is pressure on companies to make sure they are positioned well for the future.
Is there currently a point of friction between your business model and your customers? When it comes to applications, this may be very difficult to recognize until you start building a mobile strategy, but because there are so many new technologies associated with this strategy, simply creating an easier path for your customer to their goal can uncover pain points that were previously unknown. A simple example of this can be found with how we used to find our way when driving. Many years ago, you would have to discover directions to your location, maybe even by calling the destination on a land-line phone and physically writing down these directions. Later, this pain point – which was unknown as a point of friction before – is eased by the Internet, and Google Maps, which could then quickly map out your directions both visually and textually, allowed you to print these directions and take them with you. No more calls, no more writing, no more hassles… or are there? Today, with smartphones, people have access to mapping utilities right in their pocket. A rendering problem aside, the new Apple Maps not only emulates a similar mapping feature as Google Maps, but also vocalizes turn-by-turn directions. Once again, a new pain point arises that maybe was not previously known (although GPS modules already have this feature). Mobile strategy development can recognize these, and provide a new path to success where none existed prior.
So what’s included here is a very wide overview of every consideration when delving into the process of creating your mobile business strategy. What’s not here is an in-depth jargon-filled tech paper that only the developers can understand. Upon finishing this paper, you should have a strong enough knowledge of the process to start building the team and relaying the project details. Leave the detailed jargon to the experts and keep your eye on vision and insight.
What Are the Considerations?
At the very least, a business creating a mobile strategy should address the following considerations, which I will analyze further below:
- What mobile devices should we develop for?
- What type of application should we build?
- How do we approach the User Interface?
- How do we approach the User Experience?
- What do we need for development?
- What capabilities does our application require?
- What limitations are acceptable with out application?
- What options does our application framework decision afford for monetization?
- How do we get our application to our customers?
- Can we support multiple versions and is this necessary?
- What is our acceptable time-to-market?
- What security concerns are there with our framework decision? With our business model?
- Is this application future proof?
These 13 questions, if answered well with the business needs in mind, should provide a very transparent model for a mobile strategy.
Types of Mobile Devices
With the mention of mobile devices, I am generally referring to smartphones and tablets. Of course, within these two segments, there lies a wide variety of hardware, operating systems, screen resolutions, security features, processing power, etc. Perhaps the greatest differentiation between devices is what operating system they are running; some of these including Android, IOS, Windows Mobile and Symbian. The decision to create a mobile strategy for your business will require a lot of consideration simply around this divide, and how your solution will, or will not, address it. Mobile devices also come in a variety of screen resolutions. There would be no way to properly show the variances within this paper, but a truly overwhelming, and yet incomplete, list of these resolutions can be found on Wikipedia at the following link: http://en.wikipedia.org/wiki/List_of_displays_by_pixel_density. This link also displays how wide the variety of devices can be, though it does include devices other than the ones in consideration with this paper.
Types of Mobile Applications
For the purpose of this study, three application types will be addressed, and considerations for device type in regards to these applications will also be included.
Mobile Web Application
The term “mobile web app” refers to an application that is viewed through a web browser. Generally a mobile web app is more limited than a native application, but when it comes to lower development cost and easier maintainability, it generally surpasses a native application. Of the three development decisions, mobile web applications are by far the easiest to implement. Depending on your business model, developing a mobile web app can be as simple as adding some media queries to your CSS stylesheet to display your current website differently based on screen resolution. Though this is quick, and very inexpensive, maintaining a strong user experience can be a challenge, one of the mobile web app’s biggest drawbacks.
Another complaint with the mobile web application is its reliability. Not only is this application type required to have an Internet connection, but also it is dependent on the service provider, the host, and the processing power of the servers, rather than on-board processing with a native app. Granted, mobile data access is quickly increasing with wireless hotspots and faster cellular data, however, any time data is moved from server to client and vice-versa, bandwidth limitations might require handling data-intensive calculations and processes within native applications. If the trend continues with increased bandwidth, this gap may soon be closed, bringing even more power to the mobile application solution. A quick way to estimate whether a mobile web app will server the needs of the business is to ask whether the browser on a desktop computer is enough, since they are essentially using the same technology. Access to a device’s native features, such as Bluetooth, cameras, accelerometers, GPS, and telephony may not be accessible.
Native Application
The term “native application” refers to software that is downloaded and run on the mobile device. This software has a benefit over a mobile web app in its full access to the native device features, as well utilizing the on-board processing. Native applications are often found in app stores, where they can be searched for and purchased or downloaded for free, which can also provide an added level of security, as well as user trust. Essentially, native applications are the Rolls Royce of mobile applications, but as with the car, they come at a high price.
Just considering development for the top three operating systems introduces three different programming languages; Objective-C for iOS (Apple), Java for Android, and C# for WP7 (Windows Phone 7), requiring native applications to be built one at a time. Development in this manner is one way to ensure idea correlation between hardware features, OS requirements and your application’s user interface, but increased development cost, longer time-to-market, and additional resources can be tough to swallow. The decision to go native can also segregate customers who are not using platforms that your mobile strategy has decided not to build for.
Hybrid Application
A hybrid application is a combination of web technology, such as HTML5 and JavaScript, and native functionality, essentially a combination of both mobile web application and native. Selecting a platform, or combination of platforms, clearly must be done with the full collaboration of your technical staff, which will be considering a number of factors. The “Write Once, Run Everywhere” mantra that comes with a hybrid application sounds very appealing, and is definitely the power behind hybrid app success, but there are some big differences with this and a native application that may prove incredibly important in your mobile strategy decision.
A hybrid application can get your brand name in front of the customer in a shorter amount of time, but if its performance doesn’t measure up to the user’s expectations it might do more harm to your brand than good. A big part of this missing expectation is with the user interface. When a customer is used to their Android device, which has a very recognizable UI, they will instantly be put off if your application appears and functions like an Apple device. This added cognitive load could be enough to send them packing.
User Interface Comparison
Each new platform poses unique restraints for User Interface designers and developers. Though this is generally not a big concern in mobile development overall, it does play a role. One of the initial concerns for UI should be the processing speed of the device. Depending on your application’s needs, the development of the UI may need to be adjusted to accommodate differences. There is also the possibility that users may move between different platforms while carrying out a single task, or many tasks. Imagine a banking user working from home to pay bills, and then needing to find an account balance later from their smartphone. What kind of expectations does this user have, knowing they are accessing the same account, and the same data, from the same company?
User Experience Comparison
The first decision that affects the mobile user experience is what technologies will be used to create the application, but what technologies are going to be used should be decided with creating a rich and satisfying user experience in mind. Because the same technology displayed on different devices will frequently render very differently, it is important to ask, what are the expectations of your users?
A recent study by PhoCusWright, Inc. showed that 37% of users experiencing a malfunction in a mobile application are very likely to leave the application and never return, with 25% of those reporting that they would have a more negative overall perception of the entire brand. This kind of data really drives the nail home when considering how much research should go into a mobile strategy. A study done by the Aberdeen Group found that businesses who have made the decision to put more resources into improving their application performance based on external factors, cited user demand as the number one factor, and customer complaints and expectations followed close behind.
Generally, user expectations are not met with a web application due to presentation as an app, but retaining the performance of the web. According to Daniel Na in “The what, why, and how of mobile applications. Connectivity and the User Experience.”, the use of standards-compliant web browsers provides a foundational functionality for both the users and developers of websites and web applications, which in turn provide a consistent user experience regardless of OS or device. This is true when simply looking at browser rendering, however, this does not take into account a web application which is built to emulate a native application, and only rings true for a responsive website type solution. If a responsive website is what you are going for, mobile devices are much more reliable and standards compliant that a PC.
One factor that directly affects overall user experience is application analytics. In a longer paper, this would definitely be broken out into its own section because of the insight it can provide to a business as they move forward with their mobile presence. Knowing how your application is performing is key to improving user experience, and organizations need to measure and monitor application performance to detect application problems before they become business problems.
Development Considerations
Before starting any mobile application development, it is essential to outline a mobile strategy to help define the application’s scope, usability, and schedule. One of the most important decisions in application development is whether to build a native application or a mobile web application. That is perhaps step 1 for the IT team, with a second question that follows if native app is selected as the choice; will this be truly native or a hybrid application? [For all applications,] programming complexity is inversely related to the platform’s access to device capabilities. In general, the same things that make a platform powerful will make it more complex to code. This complexity is multiplied for each platform if a decision to develop as a native application is made. Few businesses can afford to develop applications customized per device and OS; however, consumer demands expect that the application perform, look and feel as expected for their specific device. The right answer, every time, if you are building only for customer needs, is building native. Unfortunately, this can’t always be the only deciding factor.
The company that makes the native decision must be well aware that development for multiple devices inevitably means significant duplicated effort, as application code cannot be shared between them because of the differing languages. Apple’s iPhone and iPad devices use Objective-C, while Windows phones use .Net, and Android and BlackBerry each use very different flavors of Java. This can prove to be a very tough sell in an agile environment where reuse is the common theme, and can easily push the talks to discussing hybrid applications.
In implementing a hybrid solution, developers need to carefully select the user-preferred platforms and ensure that the choices reflect user desires and details that contribute to the total user experience, so that the correct development environment can be chosen. The possibilities of development environment seem endless for hybrid development, unlike native development, which usually is done in the specific device’s SDK (Software Development Kit). Application platforms for hybrid development have varying advantages and disadvantages. Titanium Developer can develop for iOS and Android, but Blackberry support is in beta, and other frameworks have not yet been added, though it eliminates the need to set up multiple IDEs (Integrated Development Environment). Rhommobile is an application platform that supports all the major device platforms, however it requires knowledge of Ruby, which your development team may not possess, as well as a monthly membership to use.
As new devices come online, with updated software and evolving mobile client requirements, maintaining your application is now your number one priority. This is a potential major cost, as well as a major requirement for man-hours. If your mobile strategy called for a native solution for each platform (supported), then your maintenance strategy will need to include the same. Hybrid HTML5 development can cut out wasted effort and build cross-platform apps, which work on all current mobile devices, and also require only maintaining one code base; definitely a big benefit to this decision, however; while they (hybrid applications) handle fairly simple types of apps easily, they can struggle when it comes to features that access a device’s native on-board functionality.
Application Capabilities and Limitations
Previously, the biggest drawback functionally with a hybrid application was its limitations when accessing device features. Because of growing support for HTML5, as well as extensions to the language, this is now a thing of the past. This leaves one of the only functional drawbacks to a hybrid application being performance speed, which still lags far behind that of a native application.
Application Monetization
The launch of the Apple App Store changed the way developers could profit from their applications, putting these programs directly in front of the users and collecting an immediate profit with a percentage well above the previous model. The importance of a seamless end-to-end user experience to increase usage and monetization became a core principle in the mobile apps space (Sharma, 2010). This was a native solution, and an early solution to application monetization. Since then, advertising has made the leap to mobile devices in similar ways it did previously with the Internet. The main forms of monetization for apps today are:
- Paid
- Advertising
- Virtual Goods
- Up-selling/cross-selling other goods
- Hybrid
The app store is the typical paid model, and as mentioned earlier, does not apply to the mobile web application. The next four forms of monetization have mainly come in response to the changing application market and different platforms. Platform differences can significantly impact monetization – built-in-billing & in-app commerce are key. Depending on the chosen mobile strategy for a company, the paths to monetization can be drastically different, as well as how one can collect from these methods. Once again, the Rolls Royce of applications, the native app, offers the most options, and the most startup cost.
Revenue from applications is going to depend on the future of the technology. There are three critical factors that will determine how revenues from mobile apps will play out in the future:
- Penetration of HTML5+ browsers on mobile
- Difference between the native OS support and browser access to the same API’s
- Implementation differences between various browsers
Surprisingly, even though the W3C (World Wide Web Consortium) does not suggest HTML5 will be an approved standard until 2023, the first factor mentioned above is already ringing true. Every smartphone shipped today comes with an on-board browser that is fully HTML5 capable, though there are differences in rendering. Perhaps the biggest deciding factor above is the access to API’s, which currently is only fully open to native applications.
Methods for App Delivery
This section follows app monetization because it can have direct ties, however, there are also some major considerations with delivery that affect user experience. A significant factor in the mobile technology “stack” – alongside devices, operating systems, OEMs and network operators – are the app stores. These app stores may most often be recognized as the main delivery method for an application; however, this is only true with native and hybrid applications. The understanding that accessing a website on a mobile device may actually be accessing an app, can escape the layman. There are also apps available all over the Internet that have not been introduced in an app store, or have been declined, and are now only available through other means, which most often include downloading directly from the manufacturer. As a consumer, these apps can pose a security risk in that there are no guarantees to their motives. Only organizations that have undergone a registration or vetting process get to distribute apps in an app store [which] ensures accountability and additional safety to the customer. For a business to decide on this method for their app delivery, they should also know that a question of risk could persuade a user to abandon thoughts of using a certain application.
Native applications and hybrid applications both can be found and downloaded through an app store. This searchability, as well as the channels for monetization, can be a big benefit to a company who has decided to go this route. This seeming ease of delivery, however, is not necessarily what the customer is looking for. This clutter on a device may be more than the customer is looking for. How important is it that a companies’ offering be available offline, and is this tool important enough that a customer wants access to it 24/7? A mobile web application can be accesses directly online and does not need to be downloaded, having a very lightweight footprint on the user. If this use case fits closer with the business model, then a web application, or perhaps a hybrid application is the right path.
Software Version Considerations
As with delivery for native applications, software version updates are delivered the same way and a good app store will notify users when new updates are available using a centralized mechanism. This is a very useful tool for versioning your software, and can help to quickly transfer users to the newest version. This is not, however, a guarantee that all users will be on the same version, and it is important for the user experience, that if you have a native or hybrid application, all versions are supported and work as expected.
Web applications are the winners in this realm. Just like a website, a user visits via a browser and they are served the latest version. No additional considerations need to be made, and no additional versions need to be supported.
| Native Application | Mobile Web Application |
| Downloaded onto a mobile device | Accessed through a mobile device’s web browser |
| Installed and runs as a standalone application (no web browser needed) | No need to install new software |
| Users must manually download and install app updates | Updates are made to the web server without user intervention |
| There are stores and marketplaces to help users find your app | Harder for users to find with no apps store |
| Hybrid applications can be deployed to the app store | Hybrid applications can be deployed to the app store |
Time-to-market and Costs
Many mobile strategies call for the development to be outsourced, often because the company does not have developers as part of their business model. Although this can be a cost-saving and time efficient move, care must be taken to ensure that you’re not outsourcing your mobile strategy along with the development process. As much information as you provide to an outsourced developer, the understanding of the business model, company needs, and future planning, can only be truly known internally. Companies also need to be well aware, especially with native applications, that costs do not cease when the product is handed over. Maintenance and support costs can be highly unpredictable as new operating systems and devices are released. Many companies find themselves charged with unexpected and significant fees, even after a diligent effort to discover in advance all applicable usage fees, transaction fees, and additional development costs.
With native application development, building a single app is painstakingly slow, development cycles are long and the cost and the delay in time-to-market multiplies as each additional device and operating system is added to the launch. A mobile strategy that opts for this path may decide to build for one platform at a time. Often we hear of a new application hitting the market with the caveat, only for iOS, or only for Android, followed by the typical “coming soon” message for other platforms. This is exactly what happened last week with the company Jawbone and their release of the new Up, a fitness wrist band. All of the iOS devices are supported with their application, and down in the FAQ of the website, the line reads, “An Android app is coming soon”. Is this an acceptable answer for all of the users looking to get this new product, but lack the necessary iDevice? It must be a difficult decision to decide between an earlier product launch that segregates your customer base, and a later launch that may not beat the competition to market.
Due to the complexity in planning a mobile application, there is no possible way to suggest what something would cost without knowing exactly what it is, but only provide an estimate. Application costs involve many factors including visual design, functional design, development, testing, deployment, marketing, maintenance etcetera. Dr. Tim King, CTO of 5app breaks down application estimates into 4 categories, based on app size and function: Simple, Data List, Complex, and Enterprise. The following table illustrates just how wide this cost variance can be:
Even with this table, Dr. King goes on to say “It’s safe to assume that using traditional development techniques to create a simple single-platform app will cost around £10K and a cross-platform enterprise app won’t come in under £100K.”
Security & Privacy Considerations
Many organizations bring security to the forefront of web application design only when an incident occurs. The result is generally an expensive, knee-jerk, reaction to security problems that might have been avoided with intelligently planned controls. With the growing concerns over mobile security, this is a very flawed policy. Mobile phones are unique from desktop and laptop PC’s in that they feature always-on connectivity and cloud synchronization, which can increase the threat to mobile data. Mobile threats vary in scope and severity, including malicious applications, botnets, spyware, and phishing. Most of these terms have become household names, but few realize that their mobile devices are also susceptible to attack. Depending on the application function, whether it is simply presenting information, making mobile payments, or transmitting confidential data, the choice of which application framework to use can make a huge difference in measures needed for protection.
Organizations often do not protect their applications because they do not fully understand how popular security controls, such as firewalls and vulnerability scanning, relate to the application layer. This often is a direct result of the “need for speed” aspect of trying to get time-to-market down, rushing to a decision and passing it down to the development team. Making sure that development team has a trained security expert can save the aforementioned knee-jerk solution. This is the security plan in place for my personal blog, which has nothing important… at all… that I need to protect, but when I was running an e-commerce website with millions of customer records, security was always a top concern. Most companies recognize this from the standpoint of the website, but fail to understand that simply extending this to a web application or native application adds additional security concerns. Remember, building security into the development may generate some additional initial costs, but hiring a “cleaner” who has no intimate knowledge with your code-base will always end up costing more, both financially, and with your users trust.
Every day we hear news of websites being hacked and user data being stolen. These are not small websites like my insignificant blog, but large companies and government organizations like Yahoo, Facebook, and the FTC, and in fact, a survey done by Computer World shows that 90% of companies say they’ve been hacked. This type of statistic seems to present the certainty that your website will be hacked, but it doesn’t seem that we hear the same news about mobile devices and applications. Researchers suggest, however, that with the increased processing power and memory, increased data transmission capabilities of the mobile phone networks, and with open and third party extensible operating systems, phones [and tablets] become an interesting target for hackers. It would seem then, that the threat of hacks that has been expected and not materialized, is still expected and most likely imminent.
Prepare for the Future
Companies, due to the rigidity of their internal structures and culture, often have great difficulty in keeping up with technology. Users, on the other hand do not, and quickly pick up the latest devices, still expecting a perfect experience. But is this the future that needs to be planned for, or is there something else that needs to be addressed? Futurist John Smart, founder of the Acceleration Studies Foundation, looks beyond 2020 and sees apps as merely a passing phase in Internet evolution. “Apps are a great intermediate play, a way to scale up functionality of a primitive Web,” he said, “but over time they get out-competed for all but the most complex platforms by simpler and more standardized alternatives. What will get complex will be the ‘artificial immune systems’ on local machines. What will get increasingly transparent and standardized will be the limited number of open Web platforms and protocols that all the leading desktop and mobile hardware and their immune systems will agree to use. The rest of the apps and their code will reside in the long tail of vertical and niche uses”.
But who is planning on next going to market in 2020? Business is today, and a plan needs to be made for today and the next few years at least. There is a huge unknown that can only be speculation at this point when it comes to the future of mobile applications, but for today, software makers must balance the Web-vs.-native debate based on an application’s primary objectives, development and business realities, and the opportunities the Web will provide in the not-so-distant future. Oh, by the way, did anyone mention app-enabled televisions?
Conclusion
There are way too many things to consider to jump blindly into creating a mobile strategy. Each of the topics that I reviewed for this paper could fill an entire book, and probably already do. I’m simply trying to combine all of these questions together to see if an overall pattern emerges that can help solve some of the toughest questions, or at least provide an educated starting point to conduct further research.
There seem to be some simple decisions where business needs are so completely obvious that only one solution is relevant. Take the case of highly interactive game companies. As of now, there is no possible way a mobile web app, or even a hybrid app, could match the power of a native application for graphics rendering. EA Games has many titles where I’m sure nobody in the boardroom suggested a web app could be the best route to take for development. It is also easy to imagine a one page website with instructions on how to bake sweet potatoes would probably not need to spend thousands of dollars on a native application solution.
I have recently noticed a trend within larger companies who offer multiple mobile solutions, which include web applications and native or hybrid applications, often with a different solution for different divisions of the company. This makes me think of the “siloing” aspect with enterprise architecture studies and I wonder how these companies are organizing their data for so many points of contact, but that would be another paper. An example I found of this recently was Showtime. They have a very useful mobile web application if looking for high-level information, but they also have options to download full-blown applications to really utilize the media they provide. I was impressed with the distinction they made between these different options and felt I understood the reasoning. Another company, who is moving in this same direction, with less success in my opinion, is Comcast. I recently tried to download an application to view my onDemand content from Comcast and found multiple applications in the app store, with very little information on what each one did. I ended up downloading three of these, all with incredibly similar names: XfinityConnect, Xfinity Player, and Xfinity TV. After opening each one, I’m still not entirely sure why I have three, or which one I use for watching live TV, managing my account, watching onDemand content, or watching premium channels, if I even can. These two cases seem to have many similarities with very different user experiences attached, reflecting the importance of a well thought out mobile solution.
I have watched companies struggle to make a mobile strategy decision, as well as companies struggle to recover from poor mobile decisions. It is an incredibly complex decision, as most business decisions are, but because of the infancy of the industry, few possess the knowledge to intelligently make this kind of decision alone. A close, high-level, look at each of the aforementioned categories can provide either: A. Knowledge enough to make an informed decision, or B. Knowledge enough to find the right person to make the decision. I have met very few people who had a good understanding of each aspect of the SDLC (Software Development Life Cycle), let alone thorough knowledge of advertising, marketing, IT security, graphic design, or a slew of other relevant fields in mobile strategy development. Perhaps this paper can provide a good starting point for recognizing weak areas so that further research can be done? In fact, my conclusion after writing this is that I have realized just how much valuable information is out there, and I need to do further research on my weak areas, which consists of just about the whole shebang.
Technology for hybrid application development has come a long way in a short amount of time, and continues to quickly progress. The ability now to access nearly every native feature of a mobile device does wonders for the scalability of this kind of solution. That combined with the lower cost of development and maintenance makes for a nearly perfect mobile solution. Though this technology cannot perfectly replace a native application, the features, user experience, low cost, readily available tools, developer network etc. make for a foundation that should satisfy 90% of business needs. The new decisions moving forward will be what flavor of hybrid application do we develop?
Recommendations
Users have their expectations, and those are going to be based on what you, as a business, have presented to them. One important thing to keep in mind as you build your mobile strategy is to keep your own expectations realistic. The power of mobile technology, and the extremely persuasive “cool factor” of getting involved in this, can quickly turn a simple strategy into a complete refactoring of the business model. Before any decisions are made, it is necessary that a business begin with the use case. What requirements are necessary to assure a quality user experience? When a thorough use case has been developed, a business will have the tools it needs in hand to move forward with the framework decision. The table below shows the considerations for a mobile strategy, and the effort required to address each one.
| Mobile Web | Native | Hybrid | |
| Cost of development | |||
| Time to market | |||
| Dynamic content | |||
| Cross platform | |||
| Use existing development tools | |||
| Use existing hosting | |||
| Controlled user experience | |||
| Use native UI | |||
| Monetization infrastructure | |||
| Easily upgradable | |||
| Requires internet connection | |||
| Speed and latency | |||
| Discoverability | |||
| Maintainability | |||
| Easy | Questionable | Difficult | |
Security
There are standards already in place for application security, so reinventing the wheel is not necessary. It only takes a decision to be proactive, rather than reactive when putting together a mobile strategy. Security can easily become a make-or-break piece of your brand if not properly handled. At the very least, performing a vulnerability assessment prior to development should be mandatory. An organization that has never done [this], is likely to immediately and significantly reduce its risk exposure by taking that first step. For businesses that feel lost on where to begin, a good place to start is to contact the OWASP (Open Web Application Security Project), whose mission is to make software security visible, so that individuals and organizations worldwide can make informed decisions about true software security risks.
Making sure security measures are in place is a great decision, but how does this work? Security cannot be planned until it is understood what needs to be secured. Does the application have access to financial information? Does the application store information, and if so, where does it store this information? What services is the application making connections to, and what is its vulnerability while it is connected? The well thought out mobile strategy should easily answer these and more questions.
When making the decision of what application type to target, it really depends on the use case. If it’s something that doesn’t really need super high performance or native feature support at a very high level mobile web is the way to go. If not, then native applications are worth looking at. That being said, many people might not want to litter their smartphones with a bunch of native applications so taking a hybrid approach where your application is available via the browser or the app store is worth looking at.
Because the majority of cost comes with the development, I have put together a few tables to get an idea of development requirements throughout the SDLC, and how different mobile decisions affect these requirements. Hopefully this provides another useful tool in making the mobile strategy. To understand the following tables, a score of 1 out of 5 requires the smallest time cost, while 5 out of 5 requires the most.
Quality Assurance
| QA Effort | Web Application | Hybrid Application | Native Application | Notes |
| Test Devices | Y | Y | Y | Devices with OS variations |
| Test Setup | 2 out of 5 | 2 out of 5 | 5 out of 5 | Native requires special deployment |
| Functional Test Effort | 2 out of 5 | 4 out of 5 | 5 out of 5 | HTML5 requires the same level of UI testing as native |
| Security test effort | 3 out of 5 | 4 out of 5 | 2 out of 5 | JavaScript code are more exposed in HTML5 |
| Performance test effort | 2 out of 5 | 4 out of 5 | 5 out of 5 | Requires a device lab infrastructure |
Software Configuration Management
| SCM Effort | Web Application | Hybrid Application | Native Application | Notes |
| Dev Devices | Y | Y | Y | Devices with OS variations |
| Dev Tools | N | Y | Y | HTML5 requires device specific dev environment |
| Code Configuration | 2 out of 5 | 2 out of 5 | 5 out of 5 | Native requires special configuration |
| Build | 1 out of 5 | 2 out of 5 | 5 out of 5 | HTML5 requires new web services and end points |
| Code Deployment | 1 out of 5 | 2 out of 5 | 5 out of 5 | JavaScript code are more exposed in HTML5 |
Infrastructure
| Infrastructure effort | Web Application | Hybrid Application | Native Application | Notes |
| Test Devices | Y | Y | Y | Devices with OS variations |
| New Runtime | N | Maybe | Y | HTML5 may require new web services and endpoints |
| New Firewall Policies | Y | Y | Y | |
| New DNS | Maybe | Y | Y |
Operation
| Operation Effort | Web Application | Hybrid Application | Native Application | Notes |
| Devices | Y | Y | Y | Devices with OS variations |
| Support Effort | 2 out of 5 | 5 out of 5 | 5 out of 5 | HTML5 and native has similar UX |
| Deployment Effort | 2 out of 5 | 3 out of 5 | 5 out of 5 |
The Application Decision
By shifting the mobile paradigm to focus on the creation of robust, cross-platform web applications in place of native applications specific to each OS, businesses will save on development costs while reaching a wider customer base than ever before. These mobile web apps are incredibly powerful, and scalable, and easy to implement. Not only that, but because of their quick implementation and low cost, they are also much easier to get approval on. This may push some business decision makers in this direction, but very often this ends up being a mistake. If your whole online business model is built around a website that simply provides information, this could be a great solution. Any time additional requirements come into play, the added complexity can quickly become more than the web application can handle while still appeasing the users.
