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

Designing Content for Multiple Mobile Devices

by Michelle Lentz, Brandon Carson

October 1, 2012

Feature

by Michelle Lentz, Brandon Carson

October 1, 2012

“Always ask why. Why are you developing for mobile? Does it need to be on mobile? Why does it need to be on a particular device? Match the mobile mindset of the users when they are using what you have designed. What will they be thinking as they access it?”

In a BYOD (bring your own device) world, where your mobile learning must work on a wide variety of devices, a big question for designers is “how do you design for that?” In this article, we attempt to help you find some answers to that question, by looking at:

  • Mobile users’ mindsets—what are the users actually thinking?
  • Differences between web, hybrid, and native apps
  • Leveraging your content management system (CMS)
  • Authoring tools
  • Best practices and tips for multi-platform content design

Mobile user expectations

We designers today spend a lot of time thinking and talking about mobile technology, but we really need to spend more time thinking about the users. They can access the learning, but they expect a lot more from designers and developers now than they did even a couple of years ago.

  • Users want near real-time access to information in the palm of their hand
  • They expect technical stability
  • They want up-to-date, credible information and content
  • They want our applications to work

Each of these expectations is a challenge to meet when we are dealing with multiple devices and operating systems in unpredictable combinations.

Furthermore, the majority of internet users will eventually—soon!—connect to our content with mobile devices first. In many Asian countries, they already do. Compared to 2011, consumers now spend 54 percent more time with their connected devices, 49 percent more time talking and texting, and 29 percent more time watching videos on their mobile devices.

What does it mean to us, as instructional designers and developers of learning content, if everyone is connecting with their phones and their tablets first? The message is clear: design for mobile first. We heard this message repeated many times at mLearnCon.

Let’s begin, then, by considering the users.

Mindsets for mobile online usage

You can convert all the courses you want to mobile, but why have them on a phone if the users’ minds are not into learning when they are using their mobile device?

One key aspect of any content strategy when you’re thinking mobile first is to fully understand user behavior. What are the users thinking? What is their experience like? As we all know, there’s a lot going on when someone has a mobile device in hand; usually other things are happening. Mobile mindsets are really interesting to think about when you are designing your content strategy.

People have a deeply personal connection with their connected devices, and this affects their consumption habits, activities, and accompanying mindsets. Are you ever without your mobile phone? Do you ever leave your house on purpose without your phone? For the most part, our phones are an extension of ourselves, a constant presence. A good place to start understanding the users is to look at their behaviors.

Here are (some of) the behaviors of mobile device users to keep in mind.

  • Mobile users engage in short activity bursts. They pop open their phones, do something, and put the phone away.
  • Mobile users move from one device to another very quickly. As users acquire more and more devices, they traverse between them, and they want to continue their experience between them: lay one down, pick another one up, and continue where they left off.
  • One in three people multi-task with their devices. They have several things going on at any given time. We need to understand why people are doing that and take that into account in our design. How much of their attention is really focused on us, on our learning content? At the same time, they may be shopping online, texting to friends, or researching something.
  • Most use of mobile devices happens between 8:30 AM and 1:00 PM. On average, people spend 47 minutes each day using their mobile devices, but that’s in chunks: a little bit here, a little bit there. It’s not all between 8:30 and 1:00, either.

People love their mobile devices, but why?

  • Almost two-thirds of smartphone owners say that mobile devices allow them to access information that helps them in real-life circumstances. For example, people frequently get lost when they are new to a city, and phones with GPS help them figure out where they are and how to get where they are going.
  • Sixty-five percent of mobile consumers agree that their mobile device quickly answers questions when they need an immediate response. Phones are fantastic performance support devices in real life. Should they do more? How can we design apps so that smartphones can do more performance support?
  • This doesn’t directly affect learning, but nine out of 10 consumers with a mobile device have accessed it while in a retail store to do some type of research or to figure something out while they are at the moment of decision. It’s a behavior that probably carries over into other situations.

Mobile modes

It turns out, according to research that Yahoo! has done, that there are seven mobile modes. These are the behaviors that people engage in while they use mobile devices (Figure 1). Our task is to figure out which ones of these, in the learning context, are key to us as we design our content.

Figure 1: Know where your audience is and what their mindset is (Yahoo! research; used with permission)

Connect mode

This covers all communications: texting, IM, email, photo sharing, social networking. The user is connecting through a phone or mobile device with someone else in the outside world.

Search

The user needs to find information, going anywhere through search engines or other services, searching. This is the mobile mindset where people are most frustrated, usually because they have to search when they are in a “situation.” This is not necessarily a leisurely mindset for the user.

Entertain

This one is fairly obvious: video (including services such as HBO, Netflix, etc.), online streaming audio (radio), and so on.

Manage

This is another area where users have a high level of frustration. Users here are managing their lives, finances, healthcare and medical matters, calendars, and events.

Inform

This is important to learning. Users are going to news sites, blogs, reading, and any other activity where they are taking in information.

Shop

This is not only buying, but also researching, doing price comparisons, and looking over new offerings.

Navigate

For some users, this represents the highest level of frustration. It’s trying to get where you’re going, using GPS.

Where are the learners and what are they doing?

So for 47 minutes a day, mainly between 8:30 AM and 1:00 PM, this is what your learners are doing. We really can’t express the importance of knowing where your audience is, mentally, when they are using your mobile learning content. If they’re going to learn, they need to be in the right mode. If they’d rather be shopping, they’re probably not going to be very successful trying to learn. If they’re frustrated because they’re trying to get somewhere, they’re probably not going to be successful at learning. Think about where they are and what their mindset is.

Connect is the mode where people spend most time—about 38 percent. But which mode(s) do you think apply most to learning? Most designers pick Search and Inform, and we agree.

A cautionary tale

However, it is still important to pay attention to what users are actually doing. A couple of years ago, one of us was doing some work with a sales training organization at a company. We built a new sales training portal for the district managers in the different retail stores so they could communicate. We brought a bunch of components into this portal, to later find out when we were in the field that the managers were just texting information back and forth to each other. They didn’t need a whole new web portal. They were using their devices to communicate with text. Sometimes it doesn’t behoove you to create a new communication channel: just leverage the one they use and know.

Mindset vs. mode

Figure 2 indexes the various mindsets vs. modes; higher numbers indicate greater likelihood of a user experiencing a particular emotion while in a given mode (this research comes from an extensive Yahoo research study, conducted in late 2011, on how people are using their devices.) Figure 2 shows marketing stats, but much of marketing actually applies to instructional design.

Figure 2: Emotional states associated with the various mobile modes

Look at the Entertain and Inform modes. When individuals are in these modes, they are more likely to feel involved and to feel curious. You can tap into that when you are designing for learning. When users explore, if they Connect to content from trusted sources, they’re happy.

Users are most likely to feel irritated when they are in either the Navigate mode or the Search mode. They get lost and can’t find their way.

Understanding these modes and emotional states is very important when designing learning content for mobile delivery.

Sharing is becoming the most powerful social element with smartphones.

Native, web, or hybrid?

Many designers are developing apps for mobile learning. There are three different types of mobile apps: native, web (or browser), and hybrid.

This is the experience most people are used to with a mobile app: they discover it, they install it, they click it, and it runs. This is what they expect, and it’s more typical of the native app.

With a web app, the user doesn’t have the same sequence. Instead, the user finds the website, and then uses a mobile browser to access and use the app. However, the mindset for users, with respect to apps, is still “discover, install, click, run.” An organization without a native app, one with only a web app, may have a mindset issue. A company that offers a mobile-optimized web app may find that calling it an “app” confuses users, who want to go to the app store to download it.

Native apps must be downloaded to the device and installed on the device. We must write them in a language specific to the operating system (OS)—for example, Objective C, Java. Developers distribute native apps through an app store and make full use of the device hardware and APIs.

Web apps reside on a server, run in a browser, and are coded once for multiple OSs, using HTML, JavaScript, and CSS. They have limited access to device hardware and data, as well as user data.

Which path should you take?

Why would consumers want a web app, rather than a native app? The biggest reason is interoperability across all platforms—the app will run on any device, regardless of operating system. However, it really comes down to a lot of factors when you are trying to figure out which way to go: resources, support, target devices, what your consumers expect, and so on. Table 1 summarizes the characteristics of these two different types.

Characteristic

Native

Web

Downloaded to the device

X

 

Coded in a language specific to the device OS (Objective C, Java)

X

 

Runs in a browser

 

X

Coded in HTML, JavaScript, and CSS

 

X

Distributed via an app store

X

 

Full use of device hardware and APIs

X

 

Limited access to device hardware and data, and to user data

 

X

Table 1: Comparing native and web apps

A third way: hybrid apps

Many of the tablet apps, such as readers, are hybrids. Hybrids have the benefit of simpler data updates. With a hybrid, the app shell, which is a native app, can access the hardware (including the GPS, the camera, the audio, and so on). The user can download the app to a device and the app can access the API, but the content comes from the web. A lot of the tablet magazines are made this way. In our opinion, hybrid apps are the way to go.

User mindset and apps vs. browser

According to the Yahoo research, apps are most widely used in Connect, Navigate, and Inform mindsets (Figure 3). They are least used in Entertain, Search, and Shop mindsets, where the browser prevails. It’s a tossup between app and browser for the Manage mindset.

Figure 3: Usage of apps vs. browser varies according to user mindset

You can see in Figure 3 that people go back and forth between native apps and a web browser. They have different expectations when they are using a native app. They think it’s going to perform better than the browser, even though that may not always be true.

The developer’s problem

Consumers expect participatory content experiences. They want them to be contextually relevant (relevant to what they are doing right now), consumable with multiple devices, and they want them to be trusted and sharable. This is what they expect their experience of the learning content that we provide to be.

The problem for us with this is: What do we do? Do we design three different courses: one for the smartphone, one for the tablet, and one for the desktop?

Leveraging your content management system

In a project one of us did last year, putting in a learning management system in a very large organization, we started thinking like we did in “the old days.” We approached the challenge from an agnostic standpoint, where the content isn’t married necessarily to the delivery system. We leveraged the content management system that was running the organization’s news service. This service has hundreds of millions of users constantly coming to their web pages, and they constantly update those pages: 45,000 times every five minutes. This is truly an enterprise-level content management system.

There’s no reason why you can’t leverage the same style of content management system for learning, although your system probably isn’t serving that many people. The idea is that you have a content data store, and a way for the content to go in, whether it’s your own content or user-generated content. The content management system then serves that content to whatever devices you support (Figure 4). You have to figure out what those devices are. They aren’t all tablets and smartphones: there are more than 4,000 models of feature phones alone (they haven’t gone away, and they probably won’t go away until 2020): you may or may not have to support feature phones, but it is necessary to know which devices you must support.

Figure 4: Leverage your content management system (CMS)

Once you know the devices, begin building views and binders. This is similar to the interaction models that we once built in Authorware, and the templates that we once created in order to support multiple browsers when building websites using HTML. Figure 5 shows how we did this in the project last year.

Figure 5: Views and binders

All of the content is stored in the CMS, unformatted. The views and binders are associated with the different devices that we support. For the views, think of visual templates; those would be CSS and digital layout, optimized for particular devices. The binders are interactions—the things where you say, for example, “the drag-and-drop won’t work on the feature phones, but we want to have some kind of equivalent to the drag-and-drop interaction.” You will have to design that equivalent here, for this binder, so that if the learner is going access content with their feature phone that would be easier to use as drag-and-drop on a tablet, you will need to have that set up differently. It’s kind of basic separation of content from formatting.

The cool thing is that, although this CMS idea is a kind of enterprise-level thinking, there’s no reason why you can’t do this in a situation where you have only hundreds of learners, and not thousands. There are a lot of cloud apps that are helping with this now. To build views and binders, you need resource allocation to help you. These services do exist: at mLearnCon there were vendors in the Expo (edCetra and Xyleme) who are doing exactly this.

This can happen “on the fly,” so the binders are obviously optimized for the particular devices and for performance, and the CMS can also decide whether some particular content needs to be on the client or on the server; you do have to remove the formatting from the content when you’re thinking about all these different devices. This is a little different from thinking about different browsers—it’s different devices. You also have to take into consideration those mindsets—what people are thinking about when they’re on these individual devices. Finally, you have to set up your CMS to talk to your LMS; I believe that Xyleme and edCetra both have that functionality. Figures 4 and 5 refer only to your CMS.

Authoring tools for mobile

While we do have to convert legacy content for mobile delivery, it is important to design for mobile first, and from the ground up, when we begin designing new content. There were many tools in the Expo at mLearnCon that let you design for mobile first and that will support deployment to multiple devices. We aren’t going to say this tool is better than that tool; both of us use a lot of different tools for different clients, and everyone has their personal preferences in this area.

An important concern is converting Flash content to other formats for mobile delivery. The project example here that refers to leveraging the CMS is not at this point yet. However, there is a lot of legacy content that we want to support on tablets. What are we doing?

We have a lot of content in Articulate, which of course is all Flash content. Now the surprising thing is that a lot of the users with tablets who are requesting support turn out to be accountants—CPAs—and we really didn’t expect they would be that cutting edge. So we did a conversion, just to see what it takes and figure out if we could do that without having multiple different versions of each course. The last thing we want is three versions of one course on different devices that we would have to support. And that takes us back to that CMS model.

Articulate has a new application called Storyline. We were involved in the beta testing of Storyline during its development. It has a Publish to Mobile feature, which was turned off for most of the beta testing, so I was looking forward to an opportunity to try the feature as soon as possible. We had about two hours of Articulate content that was basic from a course development standpoint: presentation material, audio, videos, quizzes, and engage interactions. We took that right into Storyline, and it converted pretty seamlessly with no problems.

When Articulate turned on Publish to Mobile, we used it. That’s when a few peculiarities started happening. It supports iPad through an app that you download from the App Store. It supports HTML5 for non-iOS devices.

Playback on an iPad was really difficult. First we had to rebuild all 40 of the engage interactions—they just don’t publish to mobile, because they’re Flash. If you have Flash interactions, you’re more than likely going to have to rebuild them, so factor that into your planning.

There is another issue, not with Storyline, but with audio in Mobile Safari. The user has to initiate audio playback—there’s no audio auto-play. This is understandable from Apple’s viewpoint—with audio streaming, you wouldn’t want that data to stream unless the user told it to stream. However, it is still a problem for the designer. What are you going to do? Put a little play button on each screen? With the app I didn’t have that kind of problem.

Quizmaker came over in the conversion without a problem.

So the bottom line is that the experience wasn’t bad. For a two-hour course, it only took us about a week’s worth of time to get a nice iPad version. It was not possible to take the Articulate content straight into mobile without making some tweaks, but this really just reinforces that you have to optimize for whatever devices you are shooting for. Storyline is called a rapid tool; it lived up to its promise and it held up pretty well.

For legacy stuff, that’s do-able. However, that’s not the way you want to go if you’re designing from scratch.

Other things to think about

There are some other pitfalls, which we’re not going to pursue in this article, in addition to the ones we’ve mentioned (audio, converting legacy content in Flash, and interactions). Briefly, though, these are:

  • Mobile learning is still new territory. Designers and developers are out on the cutting edge of this, and there may not be ready answers yet for all problems or concerns.
  • Creating interactions from scratch can be an issue in that use of the various authoring tools requires certain skills: JavaScript, HTML5, jQuery, just to start the list. If you are not a programmer, creation from scratch can be slow and painful until you (or your team) can master those skills.
  • Cost is always a consideration. This includes the cost of development, of conversion, and of maintaining multiple versions for multiple devices. It also includes the cost of hiring, for example, a programmer or software to build an app. And finally, there are opportunity costs for each of these.
  • Think carefully about the length of time required for the learner to complete modules and courses, if you are thinking in those terms. Long modules will not work well on mobile devices.
  • Finally, ask yourself whether the content is really worth the effort to convert or to develop for mobile in the first place. Is the content appropriate for mobile?

A solid mobile content strategy is essential in order to manage these pitfalls.

Best practices and tips for mobile designs

  • Always ask why. Why are you developing for mobile? Does it need to be on mobile? Why does it need to be on a particular device? Match the mobile mindset of the users when they are using what you have designed. What will they be thinking as they access it?
  • Know the constraints of mobile, and simplify to handle:
    • Small screens—your mobile phone screen is your future
    • Unreliable networks
    • People in all kinds of situations
    • Screen resolution
    • Take one step at a time. Don’t try to do everything at once.
    • Think in terms of small chunks—small learning objects that the user can complete quickly.
    • Orientation—portrait or landscape?
    • Create a default reference design for the devices and know your device capabilities and limitations.
    • Become more aware of touch targets, gestures, and actions—how are people accustomed to doing things? What are the capabilities of your devices? People will think the app is broken if they tap and nothing happens. If they think the app is broken, they will just abandon the app and move on to something else.
    • Use technology to your advantage. You may find it better on mobile to build a game instead of converting an interaction.
    • Consider performance optimization (use the cloud). Not everything must happen on the device.
    • Use emulation for design and testing. Emulators are available for a wide variety of devices online and built into software development kits (SDKs).
    • Test and test again on the actual device. Remember to test again when the mobile device operating system updates!

Mobile is a new opportunity

This is our opportunity as instructional designers to do a reboot—to make a fresh start. Design is still the most important part of our job. When building a mobile application for learning, put your best instructional design chops to work. It’s a chance to do something great!


Topics Covered

(99)
Appreciate this!
Google Plusone Twitter LinkedIn Facebook Email Print
Comments

Login or subscribe to comment

To be sure, learners expect content to meet them where they are. We've begun to call that "Every-ware" around here. And because this is such a real need, we've totally redesigned every part of our course development process.

Sometimes we still get asked to design a Flash solution, strictly for the desktop. But more and more, other devices are critical. And even when we have both versions, in some geographies (like Asia and the Middle East) there isn't enough bandwidth to deliver the Flash version, so our lighter, HTML version is the ONLY version that gets used.

We've found that a combination of HTML, Javascript (for interactions) and CSS for adapting content to different devices works well for us. We also use an outside service to deliver the right video format to whatever device the learner may be using (there is a greater variety than ever before, thanks to differing implementations of the Android OS).

If you would like to see a course that works on all devices, done for Qualcomm, in 18 languages around the world: http://bit.ly/QT3A8M

But more interesting to me than mobile devices, or all the technology in the world, is the quality and user fit of the CONTENT. Virtually all statistics from all studies of elearning or mobile learning can be thrown out if you don't put value in the learner's hands. Conversely, if you're right on target, the content helps the learner get where s/he want to go, and reaches them on a personal/emotional level--then you totally skew the data in your favor.

I realize and respect that the topic here is on mobile delivery, but it seems we always forget to talk about what an incredible impact meeting the learner's needs can have.
First off - great article. One of the most important issues, the learner and the context of where their mindset is when using the device, is often overlooked.

It would be interesting to see that same info broken down by "smartphone" and "tablet." From purely ad hoc observations it seems that behaviors between the two are different and the findings (maybe it is solely) seem to be tied to smartphone behaviors/usage more than tablet usage/behaviors.

I would also add for things to look at: video - codecs sometimes vary in support between devices so MP4 doesn't necessarily become a one size fits all. (Though this is getting better.)

Also obviously that "mouse over/mouse on" is out.

re: app vs web =- one thing I've seen folks do from time to time is add code to their "web" site/content so that when you access it, you are prompted to "add" to bookmarks and it deposits an icon (like an app) on your desktop. The upside to this is that going forward users then access it like they do any other "apps" and since the look and feel can be just like "apps" the usage/perception often changes. This can be good for performance support type items - especially when tracking isn't a big issue.

Last, in terms of autoplay audio, you might want to check out dominKnow's Claro as they added a solution that works with mobile devices.
Related Articles