Limitations of using Web objects with the Mobile Player app

The Articulate Mobile Player app works beautifully in many respects, but I recently became aware of some important limitations related to viewing Web objects with the Player app. With the help of Technical Support, I was able to verify the scope of these constraints, which apply to all Articulate products (both Studio and Storyline). I wanted to bring two key issues to your attention if you anticipate the possibility of delivering your Web object content via the iPad, since you could encounter challenges with doing so in the situations described below. (I apologize for the very long post, but it seemed important to connect all of the dots in one place. Please note that these observations apply to the iPad only, as I have not tested any other mobile devices.)

Issue #1: If you are embedding Web objects into your Studio or Storyline productions that consist of other Articulate projects, you'll run into Mobile Player publishing issues that you must be aware of. These situations arise, for example, when you are:

• Embedding a previously published Presenter project into another Presenter project as a Web object.

• Embedding any standalone Engage or Quizmaker projects into Presenter as Web objects, as demonstrated here, instead of integrating them directly into Presenter. 

• Embedding any standalone Presenter, Engage, or Quizmaker projects into Storyline as Web objects, which is the only way they can be brought in. Note that the Studio '09 versions of Engage and QM can be imported directly into Storyline (as explained in this article on Engage '09 interactions), but they will take the form of Web objects once inside of Storyline.
  
  The Studio '13 versions cannot be imported into Storyline directly, but can be added manually as Web objects as explained here and continued here. 

The two kinds of limitations I'm describing below pertain to the "best practices" for publishing Web object content (some of which are undocumented). I should begin by noting that Articulate tutorials explain very clearly that to make a project available for viewing on an iPad, one would publish the project with the Mobile Player option selected. Then, anyone viewing that project on an iPad would be automatically prompted to download and install the Mobile Player app, which only takes a few seconds and works very smoothly for most situations. However, when Web objects are embedded in the project, the situation changes. The two main (undocumented) issues I'm aware of in this context are the following, both of which have been verified by Technical Support:

a. The Articulate project output that you're planning to insert as a Web object inside another Articulate project must be published as HTML5 output only. This means that when you're initially publishing the Articulate project content that will become a Web object inside of another Articulate project (let's call that higher-level project the "container" project), you should not select any of the publishing options other than HTML5 for the Web object project output.

Here's why: Let's say, for example, you select the Mobile Player option to publish your Web object project, as it seems like a logical choice. If you do this, however, you'll end up with a Web object that, once it's inside of the "container" project, will attempt to download a redundant copy of the Mobile Player app, instead of simply displaying the Web object content itself. Because your main "container" project already will be using the Mobile Player app, you'll get into a circular "app-within-an-app" dilemma. This dilemma can't be resolved until you republish your Web object content as HTML5 output only, reinsert it back into the "container" project, and then republish the "container" project with the Mobile Player option selected.

b. But even when you follow the procedure above, there are display errors that can occur when viewing the HTML5 Web object inside of the "container" project. For example, the content appears shoved to the right (not centered in the display area), which could make it impossible to view properly. This article, which applies to Storyline Web objects and not specifically to the Mobile Player, mentions a few possible reasons. Yet neither Technical Support nor I have been successful so far in viewing HTML5 output embedded as a Web object using the Mobile Player, since a display error has occurred each time we've tried it. Therefore, until that problem is resolved, it seems that there is no reliable way to display on the iPad an Articulate project embedded as a Web object inside of another Articulate project.

----------------------

Issue #2: If you are planning to play any Web object content OFFLINE using the Mobile Player app, you will not be able to do so, regardless of the type of Web object you have, and even if you have selected the publishing option to allow the Mobile Player to download the content to play offline. This is a limitation related to browser security, and exists regardless of whether you have embedded the content as a LOCAL Web object (which means it's included in the same local folder structure as your main project) or a REMOTE Web object (accessed from another location online). I understand from Technical Support that even the restriction on LOCAL Web object downloading is the intended functionality of the Mobile Player app, and is not considered a "bug."

Whom does this affect? This situation presents a challenge for anyone developing for audiences who might need to view the Web object content in an offline mode, such as when they're in transit, experiencing an Internet outage, or otherwise out of range. I believe it's important to communicate to clients or employers that this limitation exists and to plan around it accordingly, rather than to assume that it will work and find out at the last minute that it won't, or worse yet, find out after the content has already been deployed.

The only documentation I'm aware of that currently exists on the offline restrictions for Web objects is this Storyline article, although I understand that a similar article will be forthcoming about Articulate Studio. A related article that applies to all uses of Web objects and not just the Mobile Player is located here.

Note that this limitation also applies to PDF files that would normally be included in the Resources section of a project, since the Resources section does not appear in the Mobile Player. Although PDF files can be opened in a Web object using the Mobile Player when Internet access is available, they can't be downloaded as offline content. Therefore, I have not yet found a fast, reliable way to bundle PDF files with a project and make them accessible offline on the iPad.

----------------------

Workarounds to these limitations include the following:

1) Avoiding the use of Web objects altogether if you think your content might need to be viewed on an iPad. Articulate's official recommendation is to insert the content directly into the main project in whatever form would make it a fully integrated component. (This would mean, however, avoiding the use of Web objects to insert Engage and QM '09 and '13 content into Storyline. Instead, one would need to recreate the interactive functionality in Storyline as a native Storyline component.)

2) Making non-interactive MP4 videos of content that would be otherwise inserted via Web objects, such as by using Articulate Replay, Screenr, or another motion-capture video program. Of course, this removes a lot of the instructional benefit, but I personally am doing this in certain situations in which I absolutely must have bullet-proof display performance on the iPad, especially in offline conditions.

3) For PDF documents, creating a Web page of links with instructions for people to access and download the files in advance may be required, if the goal is to view them offline using the iPad.

I welcome your thoughts on other types of solutions or workarounds that have helped you, or that you think might useful in these situations.

I do understand that we are welcome to submit a feature request to ask for a change to the functionality to better suit our circumstances of use.

Thank you so much,

Adele