John Park is my guest blogger. I invited him to write this when I recognized my lack of clarity about the options for mobile development and delivery. I think you will enjoy his tour of our choices.
We want to use mobile devices, but which mobile?
There is great excitement about the potential of mobile devices for learning and support. It is hard to ignore the benefits of learning and information on demand, in close proximity to work. At the same time, there are all those devices out there, available, ripe for use by sellers, repairers, analysts and auditors. It makes sense to look to them.
Workplace learning professionals now find themselves in the middle of conversations about leveraging mobile devices for growth and support. What are the options? What decisions must be made to establish an appropriate mobile strategy?
Discussions often revolve around questions about native vs. mobile web apps. In a nutshell, native apps are created for a specific platform (e.g. Android, iOS, Blackberry, etc.) while mobile web apps take a ‘code once, run in all’ approach. But there is more to it than a decision about native vs. mobile. Just how far do you need to go? Want to go? Let’s look at the considerations associated with four options for mobile learning and support.
1. Mobile Website
A mobile website is a regular website that has been given a cosmetic make over to display nicely on a mobile device. There are two main ways of achieving this: 1) the website detects the width of the browser window to automatically alter the display for mobile dimensions, or 2) on loading the page, the code detects the browser to check if it is a mobile device – if it is, the user is sent to a mobile version of the website.
The first method described above is a relatively new approach called responsive design. It is gaining popularity because it is elegant, without fuss or bother. For example, if you load Qualcomm’s website from your desktop browser and change its width, you will notice that there are at least three changes in content and navigation layout. Boston Globe, Smashing Magazine, and Allison’s own site are three additional representations of this approach. While these examples are not considered to be web apps, this method might work for you, with benefits in low cost and not trivial functionality.
2. Mobile Web App
A web app is still technically a website that you load from your browser, but it does more than that.
Most mobile web apps are built to resemble a native app and even have some of the same functionality as a native app. Some examples of mobile web apps are YouTube, Yellow Pages, and Facebook. What sets mobile web apps apart from mobile websites is that they are built as an application instead of a static website and because of that, they can tap into mobile device capabilities, like using the camera or accessing the files in your device. While the technology isn’t there quite yet, advancements in the HTML5 interface with the device will enable mobile web apps to use advanced hardware features like accelerometer, NFC, Bluetooth, and more. Until then, today, we look to souped up hybrid apps as the bridge between mobile web apps and native apps.
3. Hybrid App
In essence, hybrid apps are web apps enclosed in a native app shell. Portions of the app are written with code for a native app and other parts rely on familiar web programming languages. Hybrid apps can be created using development frameworks like Sencha, PhoneGap, Titanium. They create apps that can access the device’s hardware features using web development technologies. These development frameworks allow developers to write the app in familiar web programming languages while at the same time allowing deployment of that that code to multiple outputs. Thus they become native apps that work for Apple iOS, Android, BlackBerry, Windows Phone, and more. Some examples of hybrid apps are BBC Olympics app, Wikipedia app, and Forbe’s Photos and Videos app. As you can see after touring the examples, hybrid apps allow users to easily update content displayed through standard web technologies while maintaining many advantages of native apps, like speed and access to selected hardware features on the mobile device.
4. Native App
Native apps are apps developed specifically for a single platform such as the Apple iOS or Google Android operating system. Since these apps are written for a specific platform, they enjoy full and native access to the hardware features on the device. While native apps are generally faster than the prior three options, they require the developer to write them in a specific language: Object-C for iOS, Java for Android. Apps like Instagram, Angry Birds, and Splashtop are examples of native apps.
Strengths and Weaknesses of the Four Options
|
Mobile Website |
|
|
|
Mobile Web App |
|
|
|
Hybrid App |
|
|
|
Native App |
|
|
How Do I Choose?
1. What is my budget? If you are working on a shoestring budget, creating a native app is out of the question unless you have a dedicated developer to code for native apps. In my experiences at Qualcomm, in dealing with vendors that create native apps, we’ve been quoted three to five times the amount it would cost to create a web app version of the same application.
2. How much time do I have? If you must make your content available immediately to your users, consider the mobile website approach. Unless you have a dedicated team of developers, finding the developers to create your app will take time. Mobile web app or hybrid app development could be better choices, since they rely on standard web technologies.
3. Does the app need to work offline? There are two reasons why you would need your app to function offline: 1) your target audience lacks reliable connection to the internet on their mobile devices; or 2) the content would take too long to be downloaded for use. If internet connectivity or speed in retrieving he content is a concern, a native app that works offline would be the best choice since it offers the quickest performance without needing to worry about internet connectivity. We have all experienced loading issues for videos. Remember the time it takes. Remember how often it hits a snag. If your content includes many images, audios, or videos, a native app that requires only one download would deliver the best experience, as long as the content does not demand frequent updates.
4. Are hardware features like accelerometer, sensors, NFC, and Bluetooth, important to what you want to accomplish? If the answer is yes, you have two choices: native or hybrid app. For example, if your app needs to be used in a hospital setting where patient information is beamed to your mobile device, you will want a native app that can harness the device’s ability to wirelessly transfer information. Reuben Tozman makes an appealing case for this investment in a recent post.
5. Do I need to target all devices or just selected devices? If you must target all devices, relying perhaps on the devices that already exist in pockets across your enterprise, then hybrid, mobile web app, and mobile websites are your selection. If speed and control over the user experience is of paramount importance and your business is unified in a single device, a native app makes good sense.
6. Do I need to make the app available in the app store? If you want to have your app in the Apple iOS or Google Android app store to increase its reach into the consumer marketplace, mobile website and mobile web app will not be viable choices. Note that there are app resources that focus on delivering to your enterprise, not the general public: Apperian, Partnerpedia, iOS Developer Enterprise Program.
No approach is best for all circumstances. With careful planning and intense attention to your priorities and context, you find your way to a suitable choice. This planning will provide a rationale to help you explain, create, execute and sustain the app going forward.
++++++++++++++++++++
John is a Senior Learning Technologist at Qualcomm and a graduate of San Diego State’s Educational Technology department. He is passionate about figuring out how technology can be used to enhance learning and performance for end users.
http://mashable.com/2012/09/12/web-vs-native-apps/
http://www.forbes.com/sites/fredcavazza/2011/09/27/mobile-web-app-vs-native-app-its-complicated/
http://sixrevisions.com/mobile/native-app-vs-mobile-web-app-comparison/
http://www.bluefountainmedia.com/blog/mobile-app/
http://econsultancy.com/us/blog/7832-the-fight-gets-technical-mobile-apps-vs-mobile-sites
http://buildmobile.com/native-hybrid-or-web-apps/
http://www.readwriteweb.com/mobile/2012/01/hybrid-html5-apps-are-more-les.php
John, your article is timely and well written. The missing element is addressing the larger issue of designing and creating content once and publishing to all platforms. For those of us who date back to the pre-Windows days of Mac only multimedia, we thought we had finally settled on a ubiquitous solution: Shockwave (first Director then Flash). Now, we find ourselves once again faced with a plethora of platforms and no single solution. Add to this the fact that we finally had a screen size that allowed for full resolution screen captures and legible photos and video; and now, due to the form factor resolution of mobile devices, we have been returned to the world of 320×240, 640×480, and 800 x 400. These smaller sizes make converting existing eLearning courses “as is” impossible. So, in addition to determining what type of application to build, we must also keep in mind the content being deployed through the application. Thanks for blogging! – Ken
John,
This is a great intro to the choices we, and anyone else considering a mobile solution to deliver any type of content or service to their mobile users. From where I stand thats an important aspect that many in the ‘L&D’ world often overlook which is, we don’t own mobile and that most organizations who incorporate mobile strategies at any level have probably already made decisions about direction and such. Not only that but alot of the content we would like to ‘repurpose’ for our ‘mobile’ exists already. The work of L&D I believe is to figure out how to create the least amount of digital waste and obstacles to content and understanding how the rest of the org made their decisions in this space is great learning for us.
Thanks
Hi Ken, thanks for your comment! The point about single sourcing to multiple platforms is definitely an interesting one; using tools like PhoneGap does allow you to write once then export to multiple platforms but fragmentation of different versions and sizes definitely is a concern for the developers.
Other considerations are:
1 Security
2 Stability – a web based app can go down or have problems where there is no reception. A native app is always available after being downloaded.
3 Delivery – Dealing with a large number of users, a web app may be easier. A non-public app needs a specific setting on the Apple Store. An Android app can be delivered via email.
We’ve set up a sandbox for exploring content development.
I’d attend a half-day workshop with the developers of MASLO. I’d realized that we needed to wrap our heads around the ID of m-learning. What does developing mobile content entail in our context–higher education–where by and large instructors are responsible for content development.
http://academiccolab.org/maslo/
What piqued my interest with MASLO is that it’s designed for exactly this type of audience–non-designer content producers. It’s extremely low-threshold, which is good. My colleague and I are sandboxing only the authoring component of the system with an eye towards the question, “what do faculty need to know to be able to develop good mlearning content”. Some of the answers will likely be technical specs, others will involve ID specs.
I’ve got a couple of other m-learning initiatives going on. Very simple and slow moving. I’m into slow design, because by and large non-designers are doing the designing.
Your experiences seem to mirror what we have encountered at my company in the last few years. When we were developing a mobile application for our sales agents we decided on a mobile website because we weren’t yet sure what device the agents would be using so we needed the tool to be compatible with a variety of devices. Of course, now our sales agents are reliant on a solid internet connection when presenting information to customers, which can be tricky considering these particular agents travel all over Southern California. Now that we have committed to iPads, we are going back to consider a native or hybrid app to increase speed and remove the need for an internet connection.
Also, I second Ken’s comment about seemingly harkening back to the old days of web development. I have made that very same comment myself when describing how the new mobile platforms has us all in a bit of waiting game as we see who “wins out” and becomes the leading technology solution for mobile platforms.
Great reminder about all the variables to consider for mobile development.
Thank you Allison for inviting John to make this great contribution. Too many people consider “mobile” as a single delivery mechanism and as John points out – it is much more than that. John’s piece along with the considered comments will make a great introduction for anyone considering going mobile with their learning.
Hey very cool blog!! Man .. Excellent .. Amazing .
. I’ll bookmark your website and take the feeds also? I am glad to search out a lot of useful information here within the submit, we need work out extra strategies on this regard, thanks for sharing. . . . . .
This article is truly a pleasant one it assists new net
visitors, who are wishing in favor of blogging.
Thank you so much for this. I needed to read this.!!