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.
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.
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?
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.
Tablets are not normally carried at all times, but their use is growing rapidly in education and training. While 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:
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)
This is the ratio between the longer and shorter dimensions of a display.
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.
(from Elearning Guild, 2013)
Keep in mind that these sizes can vary with the age of the audience.
(from Elearning Guild, 2013)
For more information on designing for the mobile platform, see the following human interface guideline documents:
Every mobile browser uses one or many of these modes of navigation:
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?
iPhone Browsing (multiple windows)
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:
For more information on capabilities, see the Learning Design>Mobile Device Capabilities to Consider section of the Guide.
All mobile devices are not created equal. Consider the following issues when deciding on a mobile development and design strategy:
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: http://www.videomaker.com/article/14520-video-formats-for-cell-phones
For the best results of supporting video across multiple platforms, take a look at the Universal Video Encoding for MP4 article here: http://blog.zencoder.com/2010/09/30/how-to-encode-video-for-mobile-use/.
Apps 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!
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.
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)
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:
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.
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?
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)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.
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: http://phonegap.com/start. 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 (http://build.phonegap.com) you will receive a native package that you can download, sign, and distribute to the App store of your choosing.