Your Source for Learning
Technology, Strategy, and News
ARTICLES       RSS feed RSS feed

Before You Begin: What to Know about mLearning

by Anita Rosen

February 27, 2012


by Anita Rosen

February 27, 2012

“Your choice is to create mobile apps or to create Web apps. There is a strong, fundamental, difference between these approaches.”

As consumers acquire more and more mobile technology, they are pushing organizations (especially their employers) to deliver information and services via that technology. Unfortunately, not all information and services are appropriate for a small, mobile, format. Online training and support is often a case in point.

At the same time, training organizations are under pressure to support learners at the time and place of need, using the devices that the learners are using. This means developing both instructional and support content for the mobile environment in spite of any difficulties. To do this, it’s important to understand the basics of the available technologies; and how to deploy these technologies in an effective way. In this article, I outline some of the key basics.

Mobile devices, for the purposes of this article, include both smart phones and tablets. Although they are computers, tablets such as the iPad, the various Android devices, and Kindle Fire are more like big smart phones than they are like desktop or laptop computers. That is to say, tablets use the operating systems and browsers found on smart phones. Tablets, of course, have more screen real estate, but tablets and smart phones share many limitations, such as processor power and memory. How can we overcome these issues?

Two choices

There are two different methodologies designers and developers can deploy to create content for mobile devices. Each methodology has its benefits and limitations and you must decide which way to go early in the development cycle. To do this you must consider the pros and cons of going in each direction, along with the needs of your project. Unfortunately, most people like the benefits of each approach and are not happy with the limitations. Currently, the best you can do is mitigate the limitations so that you have the best-available solution even if it’s not the optimal one.

Your choice is to create mobile apps or to create Web apps. There is a strong, fundamental, difference between these approaches. Mobile apps are software programs specifically designed and developed for each unique mobile platform. Web apps are Web sites specifically designed to work on all, or nearly all, mobile devices.

Developing mobile apps for mobile devices is similar to the way we developed software for computers back in the 1980’s, in that each platform is a world unto itself. If you develop an app that runs on iPhones and iPads, you will need to re-design the app and use completely different development processes for the Android, Blackberry, and Microsoft platforms because the design, architecture, and programming requirements of each platform are unique.

On the other hand, if you develop Web apps, all devices can (theoretically) access the same content and courseware. With just this bit of knowledge one would think that the best choice is to develop Web apps and not bother with mobile apps. Unfortunately the limitations of Web apps make this decision more complicated than that. Table 1 compares the two approaches.

Table 1. Web Apps vs. Mobile Apps
Requirements Web App Mobile App
App works across all mobile devices Yes No
One development effort for all devices Yes No
Text works well Yes Yes
Pictures work well Yes Yes
Test questions work well Yes Yes
Audios work well Limitations Yes
Videos work well Limitations Yes
Simulations work well Limitations Yes


Why can’t you use existing Web courses?

Since smart phones and tablets are computers with a browser one would think that content developed for computer browsers would work well on mobile devices. Unfortunately, as I indicated earlier, more than screen size limits using courses for mobile devices.

Operating system differences

To begin with, the operating systems on each type of smart phone and tablet are different, nor are they the same as they are for computers. (For the sake of simplicity, in the rest of this article, I will refer to desktop computers and laptops collectively as “computers,” even though the mobile devices we are discussing are also computers.)

Browser differences

Mobile browsers are very limited compared to computer browsers. A Web site or a Web course that works well on a computer browser may not be as usable on a smart phone or tablet, primarily because of design considerations and multimedia limitations, which I will discuss a little later.

Display differences

By design, eLearning courses are compatible with computer displays, so when creating a course for a computer the designer understands that the average width available on a display is about 800 pixels. Now, smart phones have about three times the screen resolution of a computer display. For example, iPhones have up to 326 ppi (pixels per inch), while computer displays have somewhere between 80 and 120 ppi. A smart phone’s high-resolution screens make a Web page meant for a desktop display too small to be readable or navigable on a smart phone. Of course, on a smart phone you can zoom in and zoom out of a page, but any smart phone user will tell you how frustrating it is to try to use a page by zooming in and out.

Mobile browsers do not display content in the same way that a computer browser displays it, AND each mobile device’s browser displays any given Web page differently from every other mobile device’s browser. A page that looks proper on a full-size display may look distorted on a mobile device. Furthermore, when you change the orientation of the mobile device display from portrait to landscape, the page will display differently; that is, the distortion will be different.

A Web designer using a tool such as Dreamweaver will need to spend a considerable amount of time ensuring that the pages they design will work on each device in both landscape and portrait mode. This task is very painstaking and frustrating. A designer can get a page to work on one device and then find out that the page no longer works correctly in a device they thought was already working well. Authoring tools, such as ReadyGo WCB, have engineering that adjusts their output in order to mitigate these browser and device display differences. Do not assume that a vendor has taken this last step, or that an authoring tool will make such adjustments, unless the vendor or the tool publisher explicitly states that they do.


The hot technology on everyone’s lips when talking about Web apps is HTML5. HTML5 is the latest version of HTML, the scripting language that describes what a Web page looks like. HTML5 makes it easier to create a better visual experience on the Web.

Specifically, HTML5 supports CSS3 (Cascading Style Sheets 3), a presentation language that provides the infrastructure to create the look and feel for a Web page. CSS3 allows for look-and-feel characteristics such as rounded corners and gradation; these were not available with earlier versions of CSS. Each company that creates a browser (e.g., Apple, Google, Microsoft, Firefox, Opera, to name a few of the players) has the latitude to implement as many or as few of the HTML5/CSS3 features as they wish. Computer browsers for computer displays support more HTML5/CSS3 features than mobile browsers do, and, to complicate things, all the different browsers support a different subset of features.

An untrue, but common, belief is that HTML5 ensures that Web pages will display properly in the different browsers. HTML5 does not ensure that a Web page will work well on a mobile device. HTML5 delivers about 20% of the functionality needed to get content to work well on a mobile device. That is, if you create a Web page using HTML5 there is no guarantee that this page will display appropriately on a mobile device because each of the smart-phone browsers read and render HTML differently.


Along with CSS3, HTML5 also supports OGA and VGA, which are, respectively, audio and video formats meaning that audio and video will run natively in the browser so you don’t need a plug-in. This moves us into an era where multimedia is smooth and unencumbered. Unfortunately this unencumbered multimedia is still a theoretical result; it is untested because it no one has implemented it in mobile browsers yet. This leads to the biggest limitation of going with a mobile Web solution: if you want audio and video in your course you will have limitations and a lot of work ahead of you. You will need to accept smart-phone limitations and work with the different codecs. (A codec is a program that encodes and decodes an audio or video stream.) If multimedia is the core of your mLearning experience, you should consider developing a Mobile App for each of the different players.

Multimedia can work on a Web app, as long as you understand the limitations. Most course creators have been creating courses for computers and are used to easy, ubiquitous support of multimedia. Plug-ins such as Flash do not work well on mobile devices (or do not work at all on certain mobile devices) and should be avoided. Words worth remembering: “The mobile era is about low-power devices, touch interfaces, and open Web standards – all areas where Flash falls short.” (Steve Jobs, April 2010)

All mobile browsers are designed so that multimedia does not automatically play when a page loads. That is, the user must click on something for an audio or video to play. Depending on the device and your choice of codec, by clicking on an audio or video link, the device may bring up a second window in which the audio or video plays.

Multimedia uses a lot of bandwidth, an issue about which service providers have a great deal of concern. The requirement to click before playing comes from service providers as a means of limiting needless use of bandwidth. By forcing a client to touch something before any multimedia plays, service providers limit the load on their networks. Service providers also have other ways to limit the load, including charging more for high usage and reducing service levels to dial-up speeds. Automatic play, and moving to a second page, is not a limitation of mobile apps, since you have complete control of the application you are developing.


Apple, Android, and Blackberry browsers support MP3 and WAV. You still should test your audio files to make sure they actually work in the devices you plan to support. Specifically, Android is an open platform used by many different hardware vendors. For a variety of reasons, different vendors have enabled or disabled different Android features. For example, Kindle Fire does not support Web audio. If you believe that you must provide audio for your training curriculum, you should consider Podcasting.


Video works on some mobile devices. Android supports Flash, but we don’t recommend Flash for mobile devices. If you want to include a video in a Web app the simplest method is to save your video in two formats, MPG4 and QuickTime, and place both of these videos on a page. Android learners will view the MPG4 video, while Apple users will view the QuickTime video. Currently, if you place both videos on the same page, the iPhone/iPad will only recognize and play the QuickTime video while the Android device will only recognize and play the MPG4 video. Having both versions on one page will create a good experience for people accessing video from different devices. Again, since you have complete control over the environment you have fewer issues when creating a video for a mobile app, although of course you must create a completely new app for each mobile environment.

Mobile apps and multimedia

With mobile apps you are building a software program that the learner will download, so you can build the codec of your choosing into the app. You can then create any type of audio, video, or interaction you wish. You will notice that mobile interactions tend to be much more static than interactions on a computer. Look at how much more static the screen is on Angry Birds compared to the latest computer-based video game. This is because of the bandwidth limitations on mobile devices. If your core curriculum consists of videos, you should consider creating a mobile app for each of the platforms and then streaming the videos.

The future

Over the next five years, as service providers increase their networks, and HTML5’s multimedia components become universally available, audio and video for mobile devices will become as ubiquitous as they are on larger computers. Until then, if you plan on providing mLearning to your learners, you should consider using a rapid development tool that will produce a version of eLearning courses that is compatible with mobile devices. Rapid mLearning courses designed with text, static graphics, and test questions work wonderfully as a Web app.

Topics Covered

Appreciate this!
Google Plusone Twitter LinkedIn Pinterest Facebook Email Print

Login or subscribe to comment

Not sure why you would need to provide a Quicktime video in addition to an MP4 as iOS devices also support MP4 files encoded to H.264.
What is considered a rapid development tool for ML?
ReadyGo WCB is a rapid development tool for mLearning.
I appreciate the author getting the discussion started, but it seems a bit one-side because she works for a company that develops software that helps you create Mobile Apps. Read with a grain-of-salt.

Also, I have created HTML5 eLearning courses that integrate audio and video without any difficulty. By the way, the two video containers you need are MP4 (using the H.264 codec and AAC or MP3 audio) and OGG (using Theora codec with OGG audio).
If you have a grain of salt to suggest, it would be good to know what it is. 8-)
I wish it was as simple as the codecs that they list on their web sites. There are a lot of variables to having videos work well on a SmartPhone. Yes, Apple supports MP4, but they provide much better support for QuickTime. Additionally Android supports video without the need of a second screen. So my abbreviated discussion should have said you "should" provide a directly imbedded MP4 for Android with a click to second page access for Apple users to a QuickTime video. Again, video is a quagmire for web apps.
Great intro article. FYI, for video we've been using h264 codec, delivering in mp4 format and using a html5/flash fallback for playback which has worked great for us in developing solutions for mobile and desktop delivery. See blog post for more info.

Also, recommend learning more about responsive design, which is designing content to fit mobile or desktop based on how the user is learning. Great book.

Checkout for overview of what HTML5 offers, how to get started and tutorials.
Compared to the time required to develop different applications for various devices and their maintenance, web apps is definitely a preferred option.

Also, though there are few limitations in web apps they can be handled to a good extent using right set of media elements.

To answer rapid development tools for mLearning - While someone considers getting on board faster with mLearning, Raptivity is definitely an option to look at. They have recently released a quite a few number of interactions with HTML5 support to be used in mLearning.
Lovely idea and flawed. We need to stop thinkin about porting learning and training anywhere since it never really worked in the first place. Falling off the forgetting curve is a fact of life training folks seem to love to ignore. If it did not work in the classroom - online - elearning - mlearning why are we still talking about how to make it better?

Some small portion of the overwhelming research is here. Maybe we can stop wasting time and money and really come up with an on-the-job employee support program that really helps, empowers and enables workers who are thrown out into the workplace with the expectation that they "learned" what to do.

Does not happen that way. Maybe if training development people would get out there and try and safely and efectively opeerate the complex piece of equipment on which they developed a training program they would realize we need a new approach.
Related Articles