Too often development teams start with the technology, rather than the requirements or learning objectives. The learning outcome should always be the main focus, but familiarity with the capabilities of the different types of handheld devices that learners use may open new doors, or it may even require taking a step back.
When thinking about mobile device categories, remember that the mobile device is more than just a phone. Basic mobile phones are very limited for true mobile learning. There are some mobile learning success stories that use basic text message, but these categories are primarily targeting advanced mobile devices that can enable rich mobile learning opportunities, including mobile performance support. Therefore, the following list provides a logical way to categorize mobile devices that have the most potential for mobile learning. 
SmartphonesFull browser / HTML5 support, Wi-Fi, 3G/4G, music player, GPS, video-capable, Bluetooth, touch support, camera, accelerometer, gyroscope, 3D video acceleration, etc.
TabletsSame core features as smartphones, but larger screen sizes (e.g., 7-12' screen) and optional keyboard, and no cellular voice capability.
Non-phone DevicesSame core features as smartphones, but without the cellular phone capability. For example, iPod Touch, personal digital assistants (PDA), handheld game consoles, wearable devices, or portable media players.
Mobile device categories will continue to evolve both from a function and feature perspective. The main concern  and question for mobile learning developers is: what devices and/or features are supported for the intended learners?
The majority of mobile subscribers in the United Stated as of May 2013 own a smartphone (according to the latest numbers from Nielsen). The research firm found that 61% of all U.S. mobile subscribers owned smartphones, up more than 10% since smartphones reached majority status.


Devices are equipped with various features that could be used to enhance learning. Which features do your learners have? Please access the glossary if you need more details about any of these features.
  • Camera 
  • Document viewer 
  • Geolocation 
  • Internal sensors 
  • Media viewer/ playback 
  • Microphone 
  • Notifications 
  • Search / Browse Internet 
  • Short-range communication 
  • Messaging 
  • Touchscreen interaction 
  • Voice / phone communications
  • Portability/Mobility
  • Ubiquity
  • Clock
  • Networking/ Addressability
  • Cloud storage
  • Microprojection
  • External Sensors
  • Input/Output Peripherals
  • Supplemental Memory
  • Computing Functions/Apps
  • Wearability
  • Embodiment


    When defining mobile devices, we generally refer to devices which:
    • Turn on instantly (don’t require boot-up)
    • Are carried in a pocket or purse (smartphone), backpack or briefcase (tablet) most all the time
    • Have sufficient power to last one day
    • Have input and output capabilities and a processor
    Smartphones are generally always with you, but not tablets. Bringing a tablet with you generally requires more of a deliberate decision.
    Their use is growing rapidly in education and training. There are several considerations in the decision to develop mLearning for either tablets or smartphones, or both:
    • A tablet’s bigger screen makes consuming media easier.
    • Some apps may only be available for smartphones or tablets, not both.
    • Where tablets are provided (i.e., non-BYOD) the provider is committed to less expenditure since they don’t have to pay for a cellular voice plan.
    • Smartphones are used “on the go” whereas tablets are not typically used that way.
    • Tablets are often shared with others. Smartphones are generally more private and personal.
    • Smartphones are preferred for communication, “content snacking”, and mobile apps. Tablets are used for consuming media and browsing.
    While the iPad is one of the most well-known tablets on the market, several others are now available on other platforms and in various screen sizes:
    • Excite Tablet (Toshiba)
    • Galaxy Tab (Samsung)
    • Iconia (Acer)
    • Kindle Fire HD (Amazon)
    • Nexus 7 (Google)
    • Nook (Barnes & Noble)
    • Playbook (BlackBerry)
    • Surface (Microsoft)


    Screen Resolution

    Various screen sizes
     How many pixels (width x height) are available on your target audience's device(s)? This is important to consider when creating graphics for mobile screens. If the image is too big for the device, it will be resized, which results in poor image quality. If the image isn't big enough for the device's display, it may look awkward with blank space around it, which may interfere with your overall design. See a complete list of mobile device screen resolutions, sorted by brand and model. Also see a list of the most popular resolutions, so that you can baseline your mobile learning interface design for the widest possible audience.
    Note that the screen size is the diagonal measurement of the screen in inches, whereas the resolution is the number of pixels on the screen. Resolution is always expressed as width by height, for example, 640x480.
    It is recommended that you stick to using design templates for both paper sketches and authoring tool screens that are sized to the target platform size right from the beginning. Do not use any other size, no matter how temporary. (Elearning Guild, 2013)

    Aspect Ratio

    This is the ratio between the longer and shorter dimensions of a display.
    • Horizontal (landscape) devices have displays that are wider than they are tall
    • Vertical (portrait) devices have displays that are taller than they are wide
    • Square screens have the same width and height
    Mobile content should be developed with an awareness of the rotation/orientation capability provided by accelerometers and should offer a consistent experience in any screen orientation.

    Text Sizes

    (from Elearning Guild, 2013)
    • For small phones, use 4pt (1.4mm)
    • For larger phones, use 6pt (2.1mm)
    • For tablets, use 8pt (2.8mm)
    Keep in mind that these sizes can vary with the age of the audience.
    In general, it is better to use bigger font sizes on mobile devices than you would for desktop screens, to reduce eye fatigue.

    Touch Areas 

    (from Elearning Guild, 2013)
    • Avoid buttons. Use bars instead. This keeps navigation controls within reach of user’s thumbs
    • Space items out so users don't hit the wrong target. 
    • In general, touch areas should be positioned and sized so that fingers do not obscure important information where they are clicking.
    • Do not tell users to “click” to interact with a button. Use "push" or "tap".

    For more information on designing for the mobile platform, see the following human interface guideline documents:


    Accessibility & Interaction

    Input Methods

    screen showing gesture
    A mobile device may support only one input method or it can support many options. Possibilities include:
    • External keyboard
    • Gestures
    • Handwriting recognition
    • Multi-touch events
    • Screen/virtual keyboard
    • Stylus
    • Voice recognition 
    Handwriting Recognition


    Every mobile browser uses one or many of these modes of navigation:
    • Focus navigation (e.g., using scroll wheel)
    • Cursor navigation (e.g., ball or scroll wheel)
    • Touch navigation, including gestures (e.g., swipe)
    • Multi-touch navigation (e.g., double tap)
    Be aware that many users use their thumbs to navigate and interact with mobile screens. Some use both thumbs at once, and some only one thumb (in cases where they hold the device in one hand). User preferences vary in terms of which hand they hold their mobile device. This has implications for design, such that you want to try to avoid putting key navigation elements in the upper corners of the screen, where they are out of reach of thumbs. (Elearning Guild, 2013).
    For more information, see Hoober (2013) How Do Users Really Hold Mobile Devices?

    Browsing and Software User Interface

    There are several different approaches to opening more than one browser window at the same time. Here are some examples of the different behaviors on mobile browsers:
    • Only one page support
    • Multiple windows
    • Windows stacks
    • Tab navigation
    iPhone Browsing (multiple windows)

    Connectivity & Bandwidth

    For most users, bandwidth is becoming less and less of an issue with the availability of 3G and 4G networks. However, connectivity will always be an important consideration for mobile development strategy. Issues to consider when addressing device connectivity and bandwidth:
    • Data Plan Cost / WiFi Usage
      • The days of unlimited data plans are phasing out. Most carriers now have placed 2-3GB caps on data usage. 
      • If you require your users to download sizeable apps or large amounts of content, then you may have to consider leveraging wifi network capabilities to offset the data usage costs that would be incurred by using your data plan.
    • Image Compression: Files must be optimized for quicker load times. To conserve bandwidth for images that have a similar composition or style, use "sprite sheets" in web apps by combining numerous small images or icons into a larger image and selecting which icon to show on the rendered page using CSS. (Elearning Guild, 2013)
    • Offline & Data Storage
      • Native applications offer several options for storing your data offline, but each OS provides a unique way to do this. If no connectivity is available, you should provide minimal user experience for an offline mode, and not create a constant dependency on a connected mode. Otherwise, you could quickly lose from your users.
      • If developing for the mobile web, HTML5 provides a means for persistent local storage of data (for times of little or no connectivity)
        • Similar to cookie concept, but not auto transmitted back to the server
        • The data remains local as keyed name / value pairs to be stored within the browser
        • Limited to 5MB

    Advanced Capabilities

    Gyroscope and advanced chips
    Smartphone competition has increased the number of sensors and other advanced capabilities made available to consumers. The iPhone 4 was the first to offer a built-in, 3-axis gyroscope. Advanced capabilities such as this can offer an enhanced experience if it is supported on the device of your target audience.


    All mobile devices are not created equal. Consider the following issues when deciding on a mobile development and design strategy:
    • An emulator of a mobile device (running on your desktop computer) is not always consistent with the actual device
    • Adobe has discontinued support of the mobile version of their Flash Player
    • Inconsistent support for pop up windows and framesets on mobile browsers 
    • Limited video support (Varying formats supported)

    Video Formats

    Examples of the preferred formats supported on some mobile device platforms are identified below. Using video will likely require some form of device detection for delivering mobile web content. The most common video formats supported across most devices are MP4 and 3GP. However, video content packaged with a native mobile app may require a specific encoding type for each platform and playback may or may not be supported. The following reference gives an overview of video formats for mobile:

    For the best results of supporting video across multiple platforms, take a look at the Universal Video Encoding for MP4 article here:

    App Development and Deployment: Native or Web? Or Both?

    Android, Apple and world imagesApps are short for “Applications” and are essentially software programs that can be used to perform a specific function on your mobile device. Apps are actually becoming more important than the devices themselves. While the devices will have a limited shelf life, your App and your personal data associated with that App will continue to exist and evolve for much longer and on multiple platforms if you so choose. The Apple App store as part of iTunes was the surprise story of 2008, becoming one of the biggest successes in mobile history. In fact, all of the other major mobile platforms have copied this App store model. 
    The biggest difference between mobile web apps and native apps today from a development perspective is that native apps can require development for multiple platforms whereas mobile web apps can require support for many browsers. The bottom line is that native apps vs. web apps is not really a debate. There is no winner and there is no loser. The choice of what to develop is an engineering and a design decision that should be based on a solid set of requirements. Think about your users and where you want to distribute your content. Mobile is bigger than just apps!

    Native Apps


    What is a “native” App? A native App is an application specifically designed to run on a device’s operating system and machine firmware. It typically needs to be programmed in a unique or proprietary language and development environment for each platform or operating system. The terms platform and operating system are often used interchangeably in the mobile industry. Deloitte estimates the cost of developing for two OSs is 160 percent of the cost of developing for one. (Source). A native App is so much more than just the look and the feel. Many things matter, including the way that data is stored on the mobile. In a native App, most of the Application is stored locally on the device, but the user data may be stored on the device, in the cloud (remotely), or both. 

    Platforms & Operating Systems

    Sometimes the term, "platform" has been used rather loosely in the mobile world and this causes some confusion because there are such things as "development platforms". For the sake of consistency, when we refer to platforms we are referring to the operating system. Currently, in the desktop world, we primarily have to deal with different variants of Windows, Mac, and Linux. In the mobile world, we have to target many more if we are looking to develop a native application. Developing for each native platform requires a specialized development approach, often coupled with an integrated development environment (IDE) or software development kit (SDK). The Wikipedia article "Mobile application development" has a comprehensive list of SDKs and other information.

    In terms of developing for Native Applications, there are so many Software Development Kits (SDKs) to choose from. This list is not all inclusive, but will give you an idea of how complicated it can be to try to develop for multiple platforms using multiple SDKs. While some of these do support limited cross-platform deployment there is no single SDK that supports every Native platform, but there are a few that come close.


    Also see: List of platform development environment / SDKs (list provided by Wikipedia)

    App Marketplaces

    Each mobile device today usually provides direct access to a specific platform App store, but not all App stores are accessible on each platform since they are proprietary and unique to each device’s operating system. For example, iOS Apps packaged for iPhone, iPad, and iPod Touch won’t be discoverable in the Android Market (recently renamed Google Play). Each App store has a unique process, file formats, and specific requirements for distribution to their App store. The process of distributing your App to these different App stores for each platform can be very time-consuming and should be considered in your overall distribution strategy. Below is a listing of the primary native App marketplaces available to mobile devices in the United States:

    Native Apps Pros and Cons

    • Faster performance because they can directly access the mobile device's hardware. 
    • They offer a best-in-class user experience, offering a rich design and tapping into the full range of device features.
    • They do not require connectivity, though can be designed to connect to any kind of cloud service or web application.
    • Can make calls to other native apps on the device
    • They are relatively simple for a programmer to develop for a single platform.
    • They require a unique programming language.
    • Updates generally require downloading a new file.
    • They cannot be easily ported to other mobile platforms.
    • Developing, testing, and supporting multiple device platforms can be costly.
    • They may require certification and distribution from a third party that you have no control over.

    Mobile Web Apps


    The differences between mobile web apps and native apps are anticipated to be less obvious by users in the near future. Modern mobile browsers can now gain direct access to the hardware capabilities of mobile devices (including accelerometers and geo-location).
    The performance of browser-based mobile web applications continues to improve. Persistent storage and access to user interface functions (such as the address book) may further reduce the demand for platform-specific native apps. As far as today's mobile web apps are concerned, most of the data is stored in the cloud.

    When to Develop

    • When you seek cross-platform compatibility
    • When you can't support the development of native apps using proprietary SDKs
    • When web accessibility is a requirement
    • When the more advanced capabilities of the device aren't required

    Mobile Web Pros and Cons

    • Lower skill set required to build - uses basic HTML, CSS, and JavaScript knowledge
    • Easier to deploy across multiple devices
    • Content is accessible on any mobile web or desktop browser
    • Easier to update content
    • Can be packaged and ported as a native app! See "The Hybrid Approach" below.
    • The best user experience (interface) might not be available on all handsets
    • Requires constant connectivity (site can be cached but isn't perfect)
    • Can't call other native apps on the device
    • Can be challenging (but not impossible) to support across multiple browsers
    • Older devices don't support native application features, like offline mode, location lookup, file system access, camera, etc.

    The Hybrid Approach

    While the mobile development community argues about which is the better approach (native or web App), the truth is this: Native Apps vs. Web Apps is not really a debate! There is no winner and there is no loser. The choice of which type to develop is an engineering and design decision that should be based on a solid set of requirements. While developing a mobile web App is easier and more cost effective for development, you must also consider the end user’s view and meet their expectations for access. End users expect ease of use and the discovery of an App to meet just about any of their needs. Why not support both mobile web App and native App deliverables?
    Facebook, Google, and many other companies are supporting both types. However, these are large companies and can afford to have large development teams to support both. One alternative for any company or organization on a smaller budget is to consider the hybrid approach to support both the mobile web and native Apps. The hybrid approach gives you the best of both worlds. Hybrid Apps allow you to develop using HTML5, CSS, and JavaScript and support multiple platforms by packaging your content as a native App to be installed directly to the device.

    Mobile Development Using Frameworks

    Below is a listing of some free open-source frameworks that can be used to develop hybrid mobile Apps using HTML 5, JavaScript, and CSS. Mobile Apps developed using some of these frameworks can be written once and deployed to many platforms as both a native App and/or a mobile web App. Some of these frameworks are more mature than others, and this list isn’t intended to be all inclusive but should give you a good place to start if you’re interested in this approach. Some of these frameworks include APIs and some offer additional commercial tools or publishing capabilities for packaging the content as a native app. If you only care about targeting the newer smartphone touch devices or mobile devices that support HTML5, then this is a cost-effective alternative to native app development.
    Note that when you design using cross-platform mobile development tools, you should be aware of user expectations for the particular platform they are using. They often expect a familiar experience based on native apps for that platform. A universalized app may be annoying and not user friendly to them. (Elearning Guild, 2013)

    PhoneGap (Apache Cordova)

    In addition to using a framework for development you need a way to take your HTML-based content and turn it into a native App. While there are various options available, several are proprietary solutions and come with a service fee. PhoneGap is the most mature and widely adopted solution for turning your HTML-based mobile content into a native App. Recently PhoneGap announced that it is moving to the Apache Software Foundation (ASF) as an official open source project where it will be called “Apache Cordova.” That means it will remain free and continue to be improved by the community of developers. In the meantime, you can access all of the documentation and resources from the PhoneGap website until the transition is complete.
    Besides providing the capability to package your HTML-based content as a native App, PhoneGap also enables developers to utilize the core features of the iPhone, Android, Palm, Symbian and BlackBerry smartphones, including geolocation, accelerometer, contacts, sound and vibration. PhoneGap accomplishes this by allowing developers to utilize several JavaScript APIs they have built: Until the W3C has completed their work in providing device APIs that are standard and widely implemented, PhoneGap provides a nice solution that is widely supported by all smartphones because it’s based on JavaScript.
    PhoneGap is free; however, it currently requires you to install the SDK or an IDE for the platform you are targeting (e.g., XCode for the iPhone, Android SDK for Android, etc.). Fortunately, the documentation provided will walk you through all of the steps: PhoneGap basically works as a plug-in for each IDE or SDK to allow you to import your HTML-based content and then compile it as a native App. However, if you don’t wish to install the IDE or SDK for each platform, PhoneGap does now provide a cloud-based service where you can upload your HTML-based content. Once uploaded to PhoneGap Build ( you will receive a native package that you can download, sign, and distribute to the App store of your choosing.

    App Store Distribution Processes for Developers

    Whether you decide to develop your mobile App using SDKs or using HTML5 frameworks, once your App is finally developed you will be ready to distribute it to each of the App stores and follow several different processes. Most all of the App stores require your App to be tested and signed with digitally encrypted certificate keys in advance. In addition, you will have to generate App icons and screen captures and other metadata for your App. The App stores all have different requirements for the resolution of these icons and screen captures as mobile devices support various levels of resolution, so this can be somewhat challenging to support if you aren’t prepared in advance. Below is a listing of the developer sites where you can find the account registration process as well as the steps for signing and submitting your App to the App store and other requirements.