ArtsAutosBooksBusinessEducationEntertainmentFamilyFashionFoodGamesGenderHealthHolidaysHomeHubPagesPersonal FinancePetsPoliticsReligionSportsTechnologyTravel

6 Things You Should Know Before Jumping on the Mobile App Bandwagon

Updated on October 18, 2019
cdhundley profile image

Christopher Hundley is a parent and a writer, who writes about business and technology, and other topics of interest.

Dollars to donuts, someone's bumped into you on an empty street lately because they were staring at their phone - evidence of the prevalence of mobile Internet usage. 63 percent of Americans use their smartphone for web access, according to a 2014 Pew study, and in six short years, experts predict, most people will be using their phones to buy things...

Wait! Before you head to the Apple, Google, Microsoft, or Blackberry website to download the latest SDK or rush down the hall to your IT team with a management directive, take a breath and head to your whiteboard. Mobile app development is like any other business initiative, requiring alignment with your strategic and tactical goals, financial projections, resource allocation, and assessment metrics. Don’t send your mobile app to development hell before the first keystroke. Plan, research, and plan some more, then implement, test, and assess. To help you with that first step, here are six things you need to know before jumping on the mobile app bandwagon.

Source

You might not need one

Just because these days mobile apps are as fashionable as big hair in the Eighties doesn’t mean you need one. What are you trying to accomplish? If all you are doing is sharing text information, rather than trying to create a unique user experience, then a mobile website might be best. Save yourself the higher development and maintenance costs of a mobile app if all you are doing is giving folks another way to access the independently audited financial statements are now available online, and other terribly exciting news (no offense to all you CPAs out there).

Native vs. web vs. hybrid mobile apps

I bet you I can name one native app on your phone right now: Candy Crush Saga! Ok, you don’t have to admit it, but that’s an example of a native app - one developed with a programming language (Objective-C, Java, C#, etc.) in an SDK, downloadable from an App Store, and operating on your phone, rather than a web browser. Mobile web apps, as you might have guessed, are accessed through a web browser, and are developed with a web programming language (HTML5, CSS, Javascript, etc.). Hybrid apps are downloaded and operate on a mobile device but are produced with web programming languages. Native apps usually run at the fastest speeds but are the most expensive to develop and maintain across multiple models of mobile devices. Web browsers are cheaper to develop but lack access to mobile device-specific features, such as movement sensors. Hence, the hybrid to the rescue: a native app capable of harnessing mobile device features.

But don’t just choose what appears easiest and cheapest. Examine how people are accessing your website and your social media assets. Review any available research on your target audience’s smartphone usage, and use this information to guide where you’ll focus your efforts. Next, you'll need to know...

Source

The strengths of each platform

With all due respect to the once-venerated Blackberry (and even to the emerging Windows Phone), if you’re thinking about developing a mobile app, your starting point is likely either iOS or Android. You'll need programming knowledge of Objective-C for the former and Java for the latter. And whether you are an Apple or Google devotee is pretty much insignificant compared to how many members of your audience are. Again, take a look at your data, and use this as another guidepost to determine where to focus your efforts. The differences between each platform will have a tangible impact on your user experience, as well as your development timeframes. In general, Apple has been more restrictive in what it allows developers to do, for example, dictating the look and behavior of common application UI elements (versus Android merely recommending them). This leads to more uniformity among Apple apps, whereas Google's openness can lead to more creative designs. Ideally, despite the initial platform you choose, you'll want cross-platform capability, which requires an understanding of iOS Human Interface Guidelines (as they are standards, not recommendations), as well as underlying differences in navigation, search, data views, and contextual actions between the two operating systems. Don’t forget about differing iOS and Android smartphone (and tablet!) screen sizes and resolutions, either or risk filling your app users' mobile screens full of fuzziness, without the accompanying warm feelings.

What makes users warm and fuzzy: great UX

What exactly will your users experience when they open your app? Assuming you have a clear, singular experience in mind for all curious users, don’t send them scurrying to uninstall, or to another page (any other page!), through poor user experience (UX). Wireframe and prototype your app beforehand to ensure an intuitive navigational structure. Establish graphics and content standards in advance that are consistent with your digital assets and apply them consistently in your mobile app. Test your UX beforehand with actual users and save yourself heartburn afterward.

Of course, another part of your user’s experience is how easily they can access your mobile app in all of its (preplanned) glory. While you have no control over their network’s connection speed, don’t contribute to high latency by failing to minimize your mobile web apps' use of memory, processing power and bandwidth on mobile devices. Remember, people pay for data, and therefore, access to your website. For mobile web apps, limit your image usage and compress them to the point where the quickest load time meets the highest quality level. Also, to limit download time, send requests, searches, and the like to the background. Add a caching layer, which, while the application is running, caches elements like search results and processes in memory. And consider developing an optimal concurrent download scheme for the parallel downloading of large files, to reduce operating speed further.

Source

Can you do it? Or is this a vendor’s job?

If either of the last two sentences in the preceding paragraph made your eyes glaze over, you need to think about your mobile development process. We haven’t even begun to cover security concerns, testing, and deployments. Assuming you have a budget in the black, ask yourself:

Does my team (or do I) have the time to invest (including learning what I do not know) in developing (including planning, programming, testing, launching, and assessing) this mobile app?

If the answer to any part of that question is “no,” (or even a shaky “yes”), consider outsourcing some or this entire project to a freelance web developer or mobile app development company. It'll be a challenge. You’ve got to find somebody who understands your core business, with a robust portfolio highlighting both their software architecture and their UX experience. Ideally, you want to look for an individual with design, testing, programming, and marketing skills, as well as, preferably, industry experience. Don’t be afraid to spend a little extra on a team with access to these skill sets, because deficits in any of these areas could sink your whole mobile strategy. Don’t forget to check their references. With free development tools online, anyone can be a mobile app developer. But not everyone is a mobile app developer.

Return on investment

Wait one more minute! Before you start Googling “web developers,” look at ROI. This isn’t a question of whether you do mobile. Given its increasing importance, it’s how you are going to mobile, and more importantly, how you avoid the mad dash to prove, post-implementation, that your mobile app was a success. That’s a race more often lost than won, and no one makes it to the finish line without a case of agita. Determine well in advance what the purpose of your app is, and what metrics can be measured to gauge its effectiveness. Whether you are looking at users, revenue, leads, conversions, or other metrics, eschew the big data generated by your analytics software in favor of the right data (i.e. what your boss or investors want to see).

Source

© 2019 Christopher Hundley

Comments

    0 of 8192 characters used
    Post Comment

    No comments yet.

    working

    This website uses cookies

    As a user in the EEA, your approval is needed on a few things. To provide a better website experience, hubpages.com uses cookies (and other similar technologies) and may collect, process, and share personal data. Please choose which areas of our service you consent to our doing so.

    For more information on managing or withdrawing consents and how we handle data, visit our Privacy Policy at: https://maven.io/company/pages/privacy

    Show Details
    Necessary
    HubPages Device IDThis is used to identify particular browsers or devices when the access the service, and is used for security reasons.
    LoginThis is necessary to sign in to the HubPages Service.
    Google RecaptchaThis is used to prevent bots and spam. (Privacy Policy)
    AkismetThis is used to detect comment spam. (Privacy Policy)
    HubPages Google AnalyticsThis is used to provide data on traffic to our website, all personally identifyable data is anonymized. (Privacy Policy)
    HubPages Traffic PixelThis is used to collect data on traffic to articles and other pages on our site. Unless you are signed in to a HubPages account, all personally identifiable information is anonymized.
    Amazon Web ServicesThis is a cloud services platform that we used to host our service. (Privacy Policy)
    CloudflareThis is a cloud CDN service that we use to efficiently deliver files required for our service to operate such as javascript, cascading style sheets, images, and videos. (Privacy Policy)
    Google Hosted LibrariesJavascript software libraries such as jQuery are loaded at endpoints on the googleapis.com or gstatic.com domains, for performance and efficiency reasons. (Privacy Policy)
    Features
    Google Custom SearchThis is feature allows you to search the site. (Privacy Policy)
    Google MapsSome articles have Google Maps embedded in them. (Privacy Policy)
    Google ChartsThis is used to display charts and graphs on articles and the author center. (Privacy Policy)
    Google AdSense Host APIThis service allows you to sign up for or associate a Google AdSense account with HubPages, so that you can earn money from ads on your articles. No data is shared unless you engage with this feature. (Privacy Policy)
    Google YouTubeSome articles have YouTube videos embedded in them. (Privacy Policy)
    VimeoSome articles have Vimeo videos embedded in them. (Privacy Policy)
    PaypalThis is used for a registered author who enrolls in the HubPages Earnings program and requests to be paid via PayPal. No data is shared with Paypal unless you engage with this feature. (Privacy Policy)
    Facebook LoginYou can use this to streamline signing up for, or signing in to your Hubpages account. No data is shared with Facebook unless you engage with this feature. (Privacy Policy)
    MavenThis supports the Maven widget and search functionality. (Privacy Policy)
    Marketing
    Google AdSenseThis is an ad network. (Privacy Policy)
    Google DoubleClickGoogle provides ad serving technology and runs an ad network. (Privacy Policy)
    Index ExchangeThis is an ad network. (Privacy Policy)
    SovrnThis is an ad network. (Privacy Policy)
    Facebook AdsThis is an ad network. (Privacy Policy)
    Amazon Unified Ad MarketplaceThis is an ad network. (Privacy Policy)
    AppNexusThis is an ad network. (Privacy Policy)
    OpenxThis is an ad network. (Privacy Policy)
    Rubicon ProjectThis is an ad network. (Privacy Policy)
    TripleLiftThis is an ad network. (Privacy Policy)
    Say MediaWe partner with Say Media to deliver ad campaigns on our sites. (Privacy Policy)
    Remarketing PixelsWe may use remarketing pixels from advertising networks such as Google AdWords, Bing Ads, and Facebook in order to advertise the HubPages Service to people that have visited our sites.
    Conversion Tracking PixelsWe may use conversion tracking pixels from advertising networks such as Google AdWords, Bing Ads, and Facebook in order to identify when an advertisement has successfully resulted in the desired action, such as signing up for the HubPages Service or publishing an article on the HubPages Service.
    Statistics
    Author Google AnalyticsThis is used to provide traffic data and reports to the authors of articles on the HubPages Service. (Privacy Policy)
    ComscoreComScore is a media measurement and analytics company providing marketing data and analytics to enterprises, media and advertising agencies, and publishers. Non-consent will result in ComScore only processing obfuscated personal data. (Privacy Policy)
    Amazon Tracking PixelSome articles display amazon products as part of the Amazon Affiliate program, this pixel provides traffic statistics for those products (Privacy Policy)
    ClickscoThis is a data management platform studying reader behavior (Privacy Policy)