Is “Rapid” eLearning Design and Development Possible?

Traditional eLearning may be on its way out, but it is still with us today. In fact, some companies still rely on it heavily. It’s our job to look to the future, while also catering to present needs.

In today’s lean times, there is lots of buzz and interest around “rapid” elearning design and development. But what, exactly, is “rapid?”

In a 2008 post by Tom Kuhlman, author of the Rapid e-Learning Blog (one of my favorite blogs), it’s 40 hours. Here’s what he has to say (on another topic actually – professional narration):

Rapid elearning development has a 33:1 ratio in development time.  For every finished hour, you’re probably spending about 33 hours of work in labor.  I’m just going to keep it simple and say that it takes you a week to do a project.  That’s 40 hours.  At $100* per hour, the company is spending about $4000 per project.  That’s just for your labor.

Hmmm…I am amazed by that number. I suppose it could be true if you already had your learning objectives, course design, and content defined and were at the point of programming it into your authoring tool. I wonder if it’s true when you have to convene a team of SMEs, discuss what the course is supposed to accomplish, define a look/feel for the course, write the content, and then program it. Here’s what makes or breaks rapid for us – and rapid is not 40:1:

  • The client project manager. If you have someone who understands work plans and scope, then you will move fast. If you have a PM who allows subject matter experts to add screens, content, animations, etc. to the course, things will not be rapid.
  • Content. If it exists and is stable, then we can move quickly. If it has to be gathered from people’s heads…and people have multiple opinions about the content, things will not be rapid.
  • Limiting screen templates. If we agree at the design stage how many unique screens will be created – and stick with it (i.e. 8 or 10 different screen layouts), then we can import content quickly. If the customer – or the instructional designer – keeps wanting changes and different screen layouts, things will not be rapid.
  • Realization of what a 30-minute course really means in terms of the amount of content to develop. If the client and instructional designer  understands that 30 minutes is probably somewhere between 17-30 screens (depending on the # of pop-ups, animations, or video files embedded within a screen), then we’re good. If the designer creates a design that requires 40-50 screens, a bazillion popups, or tons of audio, sthen we will not be rapid.
  • SMEs. Quite frankly, the more you have the less rapid things will be. Wherever possible, one SME per course is optimal. Get 5 SMEs involved, and you will have 5 opinions to consider and 5 schedules to work around. This is one of the BIGGEST reasons rapid doesn’t happen more often.
  • Review cycles. If we can go from design to alpha with no script reviews, then we can be very rapid. If the client wants three review cycles on scripts/storyboards before we move into programming, we are in trouble in terms of rapid.

I might hit Tom’s # of 40 hours if I get to be the SME, the project manager, the instructonal designer, the writer, and the multimedia developer all in one and I have all the content at my fingertips with no creation of it required. The reality is that on a complex project, this is seldom the case.  I contend it’s also a lot harder to be “rapid” when you are truly trying to teach someone to do something as opposed to merely sharing information with them. So…what strategies have others evolved to achieve “rapid” AND how do you define “rapid?”

Adobe Ends Development of Mobile Flash Platform

Earlier this week, Adobe confirmed that it is ceasing development on Flash for mobile devices and will instead increase its investment in HTML5 and related tools. Here’s the message from Adobe:

“…HTML5 is now universally supported on major mobile devices, in some cases exclusively.  This makes HTML5 the best solution for creating and deploying content in the browser across mobile platforms.” – Danny Winokur, Adobe VP and GM of Interactive Development

What does this mean to you, as developers and distributors of eLearning? In the short-term, Flash will continue to be an important part of the e-Learning developer’s tool belt; there are simply too many users out there who still rely on browsers that aren’t yet compatible with the latest HTML5 and CSS standards. So if you are using tools that output as Flash (e.g. Articulate Presenter) or you incorporate Flash into your courses, you can continue doing so as long as desktop delivery is how you plan to distribute eLearning.

The rising desire for mobile learning and the accompanying goal to efficiently “build once and deploy everywhere” aren’t feasible with a solution that anchors you and your audience to a desk. (Get up to speed with our great brief “Lessons on mLearning”). If you think your organization is going to go “mobile” in the next year, it’s time to talk to us about alternatives to Flash-based solutions.

If you are already anticipating making the switch from Flash, feel free to share with us in the comments section.

Play Testing Games — An Essential Step

(We have created an 8-part comprehensive report containing a series of one-to-two page “briefs” regarding learning game design. This is part 7: Play Testing Games — An Essential Step. If you would like to see the white paper in its entirety, check out theWhite Papers section on our website.)

You can definitely brainstorm a game idea in an afternoon and build a simple prototype. However, going from the rough idea to a polished game takes iterations and time. A great game requires lots of tweaking, modifying, and refining. Creating prototypes and play testing them is critical to designing good games. Play testing is the only way you can figure out whether your core dynamics and game mechanics work.

Game play dynamics – how players react to the game and the impact of various rules and feature sets don’t emerge from your written design. They emerge as you play test, which is why you need to build prototypes. The cheapest and fastest way to play test is to start with paper prototypes. Even if you are ultimately creating an online game, first build it on paper (or perhaps in PowerPoint) to see if it works as you imagine it would. You can make changes much faster and cheaper when you haven’t invested hundreds of hours building the first rendition of your game.

* After initial play testing, you will creat a design document. You will update the design after each iteration of play testing. This is a living document, not a one-time creation.


A creative design team can come up with a simple learning game design in a few hours – and build a rudimentary prototype in a bit more than that. Once a prototype is in place, you need people to play it and other people to watch them play. You debrief the experience, and you build another, more robust prototype. However, the second rendition is STILL a prototype with many things mocked up rather than refined (e.g. we may create the cards associated with a board game in a Word table and then print and cut them up for initial rounds of play). A game board might be printed as a series of PDF pages and taped together for initial rounds of play. We avoid going to a production version until we’re confident we have the right user interface and play experience. Only after we are sure the cards are keepers do we invest the dollars in creating the polished version.

If the game is an online game, we may rough out animations and game mechanics in PowerPoint first or build one level and play it to see how we refine things before moving forward. True story: One of our biggest mistakes was with our Knowledge Guru™ game. We were so confident of our game design that we built an entire rendition of the game after documenting our initial design. Once we play tested, we found out our initial game mechanics didn’t work (translation: game wasn’t fun). We had to completely rebuild it. Ouch!

Rule to remember:

You cannot tell how fun or effective a game will be from reading a written design document. You have to play test. Game design and development is an iterative process. Be prepared to play and revise, play and revise again.

Constraints that Affect Learning Game Design

(We have created an 8-part comprehensive report containing a series of one-to-two page “briefs” regarding learning game design. This is part 6: Constraints that Affect Design. If you would like to see the white paper in its entirety, check out the White Papers section on our website.)

Here are some of the big constraints that will influence design decisions:

How much money can you spend?

If you want a virtual world with multiple levels of play and a degree of realism that rivals your actual work environment, you can spend quite a bit of money. The commercial video games such as World of Warcraft cost seven figures to create – and took years to build. However, realistic simulations of a task can be done for much less than that. We created a troubleshooting simulation for a hemodialysis machine for less than $50K in the span of three months.

A casual game – similar to the Hangman game shown here – can be done for $10-25K.


Do not reject the idea of a game because you assume you cannot afford one. Consider, too, the ROI of a game. If the learner stays engaged – and retains the info and/or builds skill through the game – how much is that worth?

How much time do you have?

If you need something more than a casual game (e.g. the Hangman game), you need at least a few months to develop it, depending on the complexity. You cannot build a successful game from a traditional testing approach, such as alpha, beta, final. You need multiple rounds of play testing and revision to ensure you get a great game. Very simple games (e.g. the Hangman game) can be done in a month or less. This Knowledge Guru™ game took us several hundred hours to evolve – even though it seems simple on its surface.

If you want an online game, what platform(s) do you want the game to run on?

This decision can make you – and/or the game developers – crazy. Trying to figure out which – and how many platforms – to support is a major decision. Creating a game for a desktop or laptop means something very different than creating a mobile game for a tablet (which, in turn, is different than a game optimized for a phone). Your platform decisions can have an impact on your budget and your timeline. If you need to develop for multiple platforms, expect your timeline and budget to increase.

Who’s the target audience?

Is the target player someone experienced or new to games? Are they 20-somethings or 50-somethings? From experience, we’ve learned that 20-somethings don’t need – or want – much direction. They want to immediately start playing, and they will figure things out as they go along. A 50-something might want a complete SECTION of directions and then want navigational cues throughout the game. Know your audience!

What genre or category of game play are you looking for or are limited to?

Some clients want to avoid everything but the most vanilla game play experiences. They do not want to blow things up, kill people, or do anything that might be perceived as negative by anyone. You have to consider the corporate culture and figure out what is acceptable within it. Avoid, however, making judgments too quickly about what is acceptable and what is not.

What features do you want?

Do you want people to be able to create their own avatar? Do you want a sound track? Do you want videos? Do you want a world with multiple levels and layers? These features all influence budget and timeline.

 Rule to remember:

Theme matters tremendously in the player’s perception of the “fun factor” of a game. A simple hangman game can become exponentially more fun, for example, when we apply a “pirate” theme to it. Check out Walk the Plank here.

Getting Ideas for Games

(We have created an 8-part comprehensive report containing a series of one-to-two page “briefs” regarding learning game design. This is part 5: Getting Ideas for Games. If you would like to see the white paper in its entirety, check out theWhite Papers section on our website.)

There are numerous ways to approach the design of a game and some can get pretty sophisticated. These are a few simple methods outlined by Brathwaite and Schreiber in their book:

  • Blue-sky – Explore lots of possibilities, apply no constraints. This is a form of brainstorming.
  • Slow boil – Given a theme and a setting (and possibly some constraints), designers go through research phase with limited direction. The design gradually emerges over time.
  • Mechanic – Pick the mechanic and then design a game to it.
  • IP – Games based on intellectual property such as Glee quiz game, Spider-Man, Jeopardy, Wheel of Fortune, etc. (Who hasn’t created a Jeopardy game at some point?)
  • Story – Developing a game based on a story. One of our designers, for example, built an entire game around the story of Little Red Riding Hood.
  • MDA (Mechanics-Dynamics-Aesthetics model) – What feeling do you want to evoke? In this approach, you ask that question FIRST – and then select the dynamic and define the mechanics or rules you think will get you there. Here’s a great example where the aesthetic – or feeling – aspect probably came first.

McKinney’s Spent game is designed to raise awareness about homelessness and make you feel differently about it.


How BLP Approaches Game Design

We’ve used Brathwaite and Schreiber’s “challenges” within their book to spark our ideas. We’ve learned that a two- to three-hour design meeting is an optimal way to spark design ideas for a game. We create small design teams of two to four people and give them the learning goal and objectives we need to meet, along with a representation of the kind of content we believe the game has to include.

From there we let them choose a core dynamic and a theme, then see what they can come up with in the span of a couple of hours. The end result is a paper prototype that we can play test as part of the meeting. We’ve gotten excellent results using this technique. We’ve even gotten brave enough to include clients in these sessions – and they love it.

Getting Started at Creating Games

(We have created an 8-part comprehensive report containing a series of one-to-two page “briefs” regarding learning game design. This is part 4: Getting Started at Creating Games.If you would like to see the white paper in its entirety, check out the White Papers section on our website.)

You can create a fully-functioning simple game in an afternoon – though, admittedly, this would be a FIRST rendition of a game – not the final version. Here are two examples of games we created in the span of two hours.

Using Challenges for Game Designers as our idea generator, we’ve created games – just for fun – on a broad array of topics such as hand-washing, chickens crossing a road, auto collecting, etc. You can too – following a modification of the four-steps outlined in Brathwaite’s book:

  1. 1. Start with a topic, an instructional goal and learning objectives.
  2. 2. Think of a theme. At this point, don’t be super-critical. Brainstorm lots of different options before picking one to move forward with.
  3. 3. Select a core dynamic, and then
  4. 4. Start defining some simple rules of play.

A Word about Themes

Themes can be ANYTHING – we had a recent team come up with a game whose theme revolved around Oscar night in Hollywood. In learning games, your themes are frequently contextual to the employee’s job or the skills being learned in the game. A few years ago, we did a game called “The Global Coaching Challenge” for a pharmaceutical company and the theme was the launch of a new drug. The goal was to be the team that launched the product in the least number of years. Since the learning goal was to improve managers’ skill in coaching employees from diverse cultures, players’ success in handling a wide array of coaching situations dictated the length of time it took them to launch their drug. Every time they successfully handled a coaching situation, they gained months. When they handled a situation badly, they lost months on the timeline.

Diving into mLearning: How to get started

(We have created an 8-part comprehensive report containing a series of two-to-three page “briefs.” This is part 8: Diving into mLearning: How to get started. If you would like to see the collection in its entirety, click here.)

Think small and not huge when you do your first project. At mLearn, we heard stories from companies such as PwC, Abbott Pharmaceuticals, the Federal Bank of Chicago, and several others. Here are tips we gleaned from others’ first efforts:

  1. 1. Think through device choices carefully – lots of people did pilots with Blackberries because those were company-approved devices. By the time pilot ended, IT departments were opening things up to include iPhones and Androids with the assumption/realization that people would use personal devices for work tasks.
  2. 2. Create a policy. You cannot require people to access learning from a mobile device; you can only make it available. You’re going to find that lots of your employees welcome mLearning – but you cannot tell people they have to take learning “on their own time.” (Though companies clearly perceive they are going to leverage time that used to be “downtime.”)
  3. 3. Decide what a good return on investment is for you. Will you save money over traditional eLearning delivery? Will you save people time? (Note: It does not appear that mobile = money savings, though simple apps can end up saving $$ if you provide people an easy way to access information in the field.)
  4. 4. Name and involve stakeholders from the beginning. For senior-level executives figure out how to SHOW rather than how to DESCRIBE mobile learning and what you want to do.
  5. 5. Pilot mLearning on a small scale before launching on a large scale. Be clear on what you want to measure in a pilot. What are you evaluating? What do you hope to “prove?” Here’s a few different examples of what “small” might mean:

What does small mean???

  • • Small might mean a very simple solution to a narrow problem (e.g., nurses are having difficulty remembering access steps to an LMS.) Nurse managers have a variety of nurses who work virtually – and frequently call at odd times requesting the access steps to the company LMS. By providing nurse managers with a simple web app that outlines the four steps to walk someone through, it means nurse managers don’t have to log into their computers to walk someone through the steps. Total cost of this solution: $2000.
  • • Small might mean “small-ish” when compared to the larger opportunity. Abbott Pharmaceuticals, which sees huge potential in mLearning for its sales force, created three different kinds of mLearning (a course, a game, and a job aid) and tested them on a single district’s sales reps. They used the feedback from these sales reps to decide which prototypes to continue developing. A note: Abbott purchased iPads for pilot testers.
  • • Small is relative to the size of the organization. PwC, which has 140K employees, did a pilot involving about 400 of them in two countries– some in the U.S. and some in the UK. They created a different solution for each pilot group and extrapolated enough information to expand their efforts to affect many more countries and many more employees. However, the mobile courses they are developing still comprise a small subset of all courses that would be available to employees. A note: As the project team encountered IT roadblock after IT roadblock, they determined their quickest path to a demo was to purchase 21 Blackberries and load a prototype onto it so they could SHOW rather than TELL executives their concept for mobile learning.
  • • Small might mean rolling out a single robust solution to a small group of people. Federal Bank of Chicago repurposed an existing bank examiner course and had six bank examiners take the mobile version of the course. The project took a couple hundred hours to do (so not small in terms of effort) but they sought feedback from a very small group of tester – and limited their exposure to failure.

Planning and Implementing Questions

Business objectives and instructional goals

  • • Why mobile as opposed to some other distribution alternative?
  • • What results do you want to achieve?
  • • Do you have a way of measuring success? How?
  • • Is this intended to support performance or is it intended as an actual formal training tool?


  • • Who cares about this project?
  • • Who benefits from this project?
  • • Are Legal and IT on board?
  • • How will this project benefit each group of stakeholders? How will it make life more difficult for them?
  • • How mobile is the target audience?
  • • How are people leveraging devices now?

Instructional strategies and implementation

  • • Who will produce the content?
  • • Does the content currently exist or does it have to be developed?
  • • What tools will be leveraged for content creation?
  • • What interactions/interactivity need to be used?
  • • What time parameters for usage are realistic with the intended audience?
  • • Can information be “chunked” into stand-alone components or does it need to be viewed/completed in a specific order?

Devices and technical specs

  • • What devices are you supporting now?
  • • What devices are the optimal choice for what you want to do? Is there a device you currently have…or one you want to gravitate toward?
  • • What other initiatives for mobile learning are going on now, or are in the planning stages?
  • • What delivery platform makes the most sense– web application or native application?
  • • Is Internet connectivity going to be a factor?
  • • Is there a need to translate material into multiple languages? (Native apps may not be a great choice if you need them available in multiple languages.)
  • • Where will content reside?
  • • What content distribution methods do you plan to use (e.g. web application or native application? QR codes? text messaging? etc.)?
  • • Who will provide the distribution service?
  • • What network will you use for distribution?
  • • What security issues must be considered?
  • • Do you need to provide training on securing mobile devices?
  • • What, if any, user support needs to be provided?

Our Bottom-Line advice?

Just do it – but make sure you’re doing it with a problem for which mobile is an obvious and appropriate solution. Also do it with proper planning. The question list here will get you started – and help you recognize that planning IS required!

Low-end tools: QR codes and SMS text messaging

(We have created an 8-part comprehensive report containing a series of two-to-three page “briefs.” This is part 6: Low-end tools: QR codes and SMS text messaging. If you would like to see the collection in its entirety, click here.)

mLearning does not have to involve an extensive budget. The use of QR codes or SMS text messaging offer viable options for creating meaningful learning experiences for people.

QR Codes

QR stands for “quick response.” A QR code is a type of bar code that is readable by dedicated QR readers – something you can download to your smartphone in mere seconds. By scanning the code with the reader, you can quickly link to information. QR Codes can be a great vehicle for mobile learning. Here are a few ideas we’ve shared with clients:

  • • Include a QR code on a product brief that links to a video showing an example of a rep successfully positioning the product.
  • • Create a scavenger hunt for new-hires that leverages QR codes. By scanning each QR code as the new-hires travel around a work site, they get facts, history, and context about different functions and people within the company.
  • • For patient support once a piece of home health equipment goes home, place a QR code on the equipment so the patient can scan the code and access educational materials from a website.
  • • For ad-hoc in-service training on a piece of medical equipment (because nurse turn-over always exceeds the frequency with which a manufacturing rep can conduct face-to-face training with clinicians) place QR codes on the piece of equipment. The nurse can scan the QR code and get the set- up instructions on his/her phone from a website.

Imagine that you have a Wellness Program and you are encouraging people to eat better, get fit, and stay well. Creating posters with QR codes and placing them around the building could be a means of encouraging people to play a web-based wellness game.

What if you want to link sales reps or customers out to a specific set of educational materials? Creating a QR code on a job aid, a product brochure, etc. could take them to a robust website that gives more information.

Creating QR codes

There are numerous websites that enable you to create QR codes. Some services are linked to analytics that will tell you how many people used your code. It literally took five seconds to create the QR code on the previous page. We used this site:

Downloading readers

Again, downloading a reader is simple and takes seconds to do. Simply search iStore or Android Marketplace for “QR Reader.” You will have several options – most of which are free.

SMS Text Messaging

Text messaging is another simple, low-cost solution that has possibilities. A variety of research reports (just Google “text messaging in education” or “educational text messaging” to get an idea) illustrate the effectiveness of sending texts to share or reinforce information. One example, shared by Partners Healthcare, focused on sending patients with Attention Deficient Disorder follow-up texts that included educational info or reminders. The results of this low-cost solution were impressive as 80% of participants improved compliance with medication and 90% reported improvements in at least one health maintenance behavior.

Such messaging isn’t only appropriate for healthcare settings. Sending out a daily or weekly text message to sales reps to remind them of product messaging or to assembly line personnel to remind them of safety tips are other useful examples of this low-cost solution.

Broadcast texts are easy to set up and numerous web-based services are available. Two of these include:

  • • (not free; costs on a per-text basis)
  • • (free)

Texting is also as an easy way to communicate or promote other mobile solutions. At mLearn, MaxHealth reported that it used broadcast texting to communicate the existence of its mobile web app to employees.

Our Bottom-Line advice?

SMS texting and QR codes both represent realistic entry points into mLearning if they are targeted to appropriate audiences. Don’t go crazy with the texting, though, or you risk alienating employees. And…ask before texting. Employees need to give you permission to send the text if the text is going to their personal device.


The link between mLearning and learning games

(We have created an 8-part comprehensive report containing a series of two-to-three page “briefs.” This is part 5: The link between mLearning and learning games. If you would like to see the collection in its entirety, click here.)

“Gamification” of learning is one of the most exciting trends we’ve seen – and it’s partially being driven by the increased interest in mLearning and mobile games in general. Gamification of learning is derived from the concept of the “gamification of the work place” and the gamification of almost everything. (See the CNN article on the gamification of reading the news online.) In the learning realm, gamification is a design strategy intended to increase learner interest, seat time, and post-learning retention. Examples of “gamification” include:

Factoring in fun/pleasure. Recognize that we do what we enjoy doing and if we make learning enjoyable, people stay engaged longer. (Contrary view: At mLearn, we talked to a person in charge of compliance training for an oil company…he bristled at the thought of training being fun. He said compliance is not about fun – it’s about safety and adhering to government regulations. While we agree, we think it’s important that people actually remember safety practices; they are more likely to remember them if they are fully engaged in learning them!)

Establishing competition and/or rewards. This ties in strongly to the concept of feedback loops, which is a known driver of behavior change. See the July 2011 article in the Wired magazine article, Harnessing the Power of Feedback Loops, on how to engineer real change in human behavior.

Making it social so people can discuss and compare their performance against the performance of others. Easy example: Game leader boards where people can compare their score against others – and keep playing to achieve higher status on the leader board or to achieve a personal best on the leader board. BLP’s own Knowledge Guru has a great set of leader boards to encourage this behavior.

If you’re ready to think about games, here are several games to download and play. Your goal is to evaluate how you can transfer the game design concepts to a learning game. Only one of them classifies as a “learning game,” but all contain elements that can be transferred to a learning game.

1. Plants vs. Zombies

(iPhone, iPad, Android)

Great example of incorporating the “rules of play” into the play itself. Early levels of the game teach you how to play without any explicit teaching of the rules. This concept leverages the fact that no one likes to read directions.

2. Cut the Rope

(iPhone, iPad, Android)

Like Plants vs. Zombies, this game does not give you rules. It is a problem-solving/strategy game that can be played in very short spurts – two minutes or less.

Note the feedback tools in the form of Levels and Stars.

3. Angry Birds

(iPhone, iPad, Android)

What can we say? People are addicted to this game. The question you need to answer is why? Has anyone in your organization ever been addicted to one of your learning courses?

The other thing to note….all your employees are only a couple clicks away from Angry Birds at any time. (Remember their phones are always with them.) If they find games more engaging – why not package your learning into games?

4. Jim and Frank’s Blood River Files

(iPhone, iPad)

This is a puzzle game and a narrative. Consider how you could weave puzzle-solving into a learning game.

5. Stack the States

(iPhone, iPad)

A quiz-style game focused on learning the geography of the U.S. As you answer questions correctly, you collect states.



Our Bottom-Line advice?

Start thinking about how you can leverage games. Learning games will be as big as mLearning itself as people look for ways to engage learners who are easily disengaged. There is tremendous potential to be tapped in using games as a means of driving behavior. Games can drive behavior and spark motivation in ways that a traditional Click Next to continue experience never will.


mLearning devices and platforms: What you need to know

(We have created an 8-part comprehensive report containing a series of two-to-three page “briefs.” This is part 4: mLearning devices and platforms: What you need to know. If you would like to see the collection in its entirety, click here.)

The issue that halts enthusiasm for mLearning is the device wars. People want to know which device to use. Our answer is that companies need to be prepared to support multiple devices and that the issue REALLY needs to be tablet versus smartphone.

Our observations gleaned from mLearn 2011 regarding devices:

  • • Blackberry produces the least appealing mobile solution. We saw solutions that had visual appeal, but you can’t get around the massive amount of scrolling required to review anything.
  • • Don’t attempt to repurpose an entire course if your end destination is a smartphone. Lots of people presented case studies of situations where they tried to do just that – and traditional doesn’t translate well. Mobile shouldn’t be viewed as simply another way to consume traditional eLearning…it should be a true solution to a specific problem that cannot be solved by a desktop solution.
  • • iPhone and Android provide similar user experiences. At a minimum, the design for each LOOKS the same. Whether users would report they prefer using an iPhone over an Android is a separate discussion.
  • • A tablet such as an iPad is preferable to any smartphone if the solution is truly a “course” versus a just-in-time performance support tool. You only want to look at/read so many tiny screens before you wish you could see things on a bigger screen.
  • • Video is an acceptable replacement for Flash. Because iPhones and iPads do not support Flash – and most traditional e-courses leverage a lot of it – there is a lot of conversion of Flash animations to video formats. This shift works pretty well.
  • • iPad dominates the tablets…but the fat lady hasn’t sung yet. Right now, the iPad and iPad2 have 75% of market share; no other device commands more than 6% of it. However, Samsung’s second generation tablet is a worthy competitor to the iPad – and it supports Flash, external devices, and upgrades – things the iPad does not.
  • • HTML5 is rapidly evolving as the authoring language of choice for web applications – and the tool that enables “build it once; deploy it across all devices.” By the end of 2011, HTML5 will be supported on all major mobile browsers. It eliminates the need to author multiple times to suit specific devices.
  • • Expect people to consume mLearning on personal devices, not just company-provided ones. At mLearn 2011 pilots all seemed to focus on company-provided devices. However, once pilots were over, the practice appeared to be that companies opened access to personal devices – and actually assumed personal devices WOULD BE the means by which people accessed mobile learning. Example: PwC started out stating the solution had to be delivered over a Blackberry. As soon as pilot concluded, they decided to allow a range of personal devices that included both iPhones and Android phones.

Web application or native application?

Not all “apps” come from an app store. A web application requires a browser and an Internet connection; a native application is downloaded to the phone – typically from an online store such as the App Store or the Android Marketplace.

There is no definitive “best choice” for learning here. There are logical reasons for choosing one over the other in specific instances. People are using both types of applications with success and companies are actually creating their own versions of app stores so employees can download company-specific apps. A few comparators:

Web App


  • • Content remains secure on your servers, no data is stored on the device
  • • Updates immediately affect all users
  • • Web-apps require no approval, fees, or placement process within a commercial app store
  • • The content created for a web app can be platform agnostic


  • • Requires Internet access
  • • Requires a web URL; you must host it on a server
  • • Less “snazzy” than a native app. Features and functionality are limited, especially with regards to access to device features
  • • Slower speed than native app

Native App


  • • Does not require Internet access
  • • Generally perform better as far as speed and fluidity (animation, graphics, UI responsiveness)
  • • Maintains full access to device features (camera/gyroscope/microphone/compass/accelerometer/GPS)
  • • Can provide a more robust experience – if one is needed


  • • Platform specific, code is not easily transported to other devices/platforms
  • • Native app stores require an approval process; for each device, the app has to go onto a different store
  • • Once the application is downloaded, it’s on the phone, which some companies may regard as a negative*
  • (*This issue is rapidly become a non-issue with some companies as they begin to realize that any emails employees download to the phone could be equally or more compromising. The benefits outweigh the risks of loss/theft in these instances.)

What about IT?

IT functions are struggling to keep up with this onslaught of mobile devices. Working with companies’ internal IT functions was cited by mLearning 2011 participants as a significant challenge to introducing mobile learning. IT departments have limited resources; they fear having to support a myriad of devices.

This quote from a recent survey by iPass summarizes the direction that needs to occur if a company has a significant mobile workforce. The bold-faced emphasis is ours:

“Do not fight the tide of mobile workers using rogue devices, such as smartphones and tablets. Mobile workers are highly productive and work more hours annually than their non-mobile peers. It is clear that your mobile professionals value tablets as a work device, and they already have a smartphone – so embrace these devices regardless if they are IT managed or not, but definitely put policies in place on acceptable use and train employees on those policies so that they understand how to secure the data on these devices.

Ensure your employees at least have access to work email on their unprovisioned smartphone or tablet. Most employees will check email before they start their workday, and this simple, but powerful tool ensures that they can be more responsive to business demands.”

Our Bottom-Line advice?

Forget about developing for only one device or for mandating Blackberry as the only supported device. The more important question is what device makes the most sense for what you want to accomplish? Do you need to optimize for a smartphone or for a tablet? If you know it’s a smartphone, then be realistic about what is palatable for a learner to consume on a phone, which is not a full-length course with lots of learning activities! If you want people to access courses, think tablet not phone.