In April I had an opportunity to deliver a presentation to PACT in Minneapolis on the challenges of designing a good mobile user experience. As more of us use mobile devices for different activities (50+% of Americans have a smartphone and 52.5 million of us have a tablet), interest in mobile learning (mLearning) continues to grow. But a successful mLearning experience has to be based on a good understanding of the constraints and opportunities that mobile devices present to interface designers and instructional designers. It will come as no surprise that designing for a smartphone is significantly more challenging than designing for a tablet. You can’t just convert or retrofit existing eLearning that has been designed for a PC so that it works well on a smartphone; you have to design specifically for that device. That means thinking differently about navigation, presentation, interactions, and content.

As a follow up to my PACT talk, I decided to sit down with instructional designer Tony Tao, Fredrickson’s expert on rapid e-learning development tools. I wanted to find out more about how well these tools can work for developing effective mLearning experiences.

[rs-image img_url=”” link=”” alt=”Tony Tao Headshot” width=”150″ height=”150″ class=”” type=”img-rounded” border=”default” new_win=”no” margin=”” pos=”pull-left” wrap=”no”/]

Image: Tony Tao

John: So Tony, let’s start with a broad question: what tools do instructional designers have at their disposal to create mLearning for use on smartphones?

Tony: John, I’m glad we can get together and share our thoughts on mobile learning. Like you said, there’s a great interest in mobile learning now that smartphones and tablets have become so prevalent. The software companies have noticed this trend too, and so when instructional designers select authoring tools for mLearning, they have some good options. The traditional eLearning authoring tools, including Flash/AIR [Note: Flash can be used to publish a course as an AIR application, which is supported by both Android and iOS], JavaScript, and HTML, are still valuable in developing mLearning programs. I’ve also noticed some rapid development tools join the game recently. For example, the newly released Adobe Captivate 6 and Articulate Storyline offer templates for tablet delivery, as well as some limited options for smartphones. There are also some interesting tools for “non-traditional” learning development. For example, iBooks Author offers tools for developing electronic books, and Xcode provides templates to develop native apps for smartphones. In addition, the most popular video editing tools are also valuable in creating mLearning.

John: Last year, you wrote a very informative series of blog entries comparing Articulate and Captivate. Do these tools have benefits and drawbacks with respect to developing mLearning that we should be aware of?

Tony: Articulate Studio and Captivate are the most popular rapid eLearning authoring tools on the market. When I wrote my blog entries a year ago, these tools were being used mainly for developing regular eLearning courses for desktops and laptops. There are some drawbacks in using them for mLearning. The most obvious problem is the cross-platform support issue. Both tools publish courses in Flash (SWF), which iOS does not support, and so this means you would not be able to view Flash-based courses on an iPad or iPhone. However, the good news is that Captivate 6 and Articulate Storyline already provide options for publishing a course in HTML5 as a way to address this cross-platform issue. However, Articulate Studio users will have to wait for the release of Studio 13, which will become available later this year with the HTML5 option.

Another problem is with some of the user interface elements of the courses that you can develop with these tools. The default navigation buttons, such as Play and Pause, and Next and Back, are good on tablets. Storyline even released a player app for iOS, so that learners can navigate through courses comfortably with their iPad. However, these buttons are still not big enough for smartphones.

John:: The screen size of smartphones definitely presents a design challenge. Navigation targets have to be big enough to accommodate fingers and thumbs in place of a pixel-specific pointer. But the more space you give away to navigation, the less space you have for content. Text size can also be a challenge, impeding the ease of reading.

Reading comprehension is another problem. A study by R.I. Singh and colleagues at the University of Alberta found that reading comprehension is reduced when people read from a mobile device, compared with a PC. One of the reasons for this is that the user has to remember more, because less of the text is visible at one time. This places an additional cognitive load on the user, adversely affecting comprehension. In Mobile Usability (2013), Jakob Nielsen describes this as “reading through a peephole.” This has to be a consideration for instructional designers.

So Tony, moving from authoring tools for mLearning to instructional design for mLearning, the question should be asked: in light of the interface design challenges, and the way in which most people tend to use their smartphones in short bursts for communication and connection, what types of learning experiences and learning content are most suitable for smartphones, compared with desktops and laptops? Is there a way to leverage the strengths of these devices in a learning context?

Tony: This is a great question. It’s very challenging to put as much content on the small screen of a smartphone as we do on the bigger screen of a PC. This dilemma can be addressed to some extent by technology. However, the solution is related more to content.

Most people who learn on a smartphone are looking for “instant answers.” This is different from the “formal” learning experience they have with desktops and laptops. An mLearning lesson running on a smartphone has to be short, maybe two to three minutes, and it has to go right to the point of what the learner needs. A good example is an instructional video. It delivers loads of content in a short period. At the same time, it uses the default navigation controls that come with the smartphone. So it saves some time that would otherwise have to be spent developing customized navigation buttons. Meanwhile, the “auto hide” feature of the default playback buttons frees more space for the content.

Another example is a customized learning app designed specifically for a smartphone. These apps can use the full controls on the touch screen, and offer the possibilities of learning through interactions.

John: I agree – a sweet spot for mLearning is just-in-time performance support. I think of the Geek Squad tech who came to our house last year to help me figure out why our TV and audio receiver were not synching. He needed to be reminded of the setting to change on our TV and found it on a video he watched on his phone.

Podcasts are another option – though they obviously don’t have the visual element. Something to bear in mind with video is the cost of data transfer, which users will have to pay for if they are using their own phone and are not using an available wi-fi network.

Going the app route, I think the challenge is to come up with something that people can dip in and out of rather than dive into for an extended time. For example, games, flash cards, or other types of quizzes would work well. Whether you go with a native app or web app would depend on the context.

Tony: You might want to check out a recent report from the eLearning Guild called “How Mobile Learning is Done.” It presents nine case studies from organizations around the world. Despite the design challenges, mLearning is only going to become more popular.

John: Agreed. Thanks very much for the info and insights, Tony!

Leave a Reply

Your email address will not be published. Required fields are marked *