Storyline 3 Crashes on iPad Safari and Chrome

Good Afternoon, all.  A quick update:

• In Storyline 360 Updates 10, 11, 12, and 13, we incrementally introduced pieces of the solution we outlined last September.  The following improvements are now complete:
  • Based on the age of the iOS device and the weight of the slide, Storyline preloads some content if the browser can handle it and keeps some content in memory.
  • If the slide is too heavy or the device is too limited, Storyline preloads nothing and keeps nothing in memory after exiting the slide. Slides will load more slowly for learners in this scenario, but it should reduce the frequency of crashing.
• The same solution was added to the release of Storyline 3 Update 3 earlier this week.

We've tested many media-rich courses, and although it is still possible to build a slide that will crash Mobile Safari (think many layers of large, lengthy videos, or high-resolution images with zoom regions) we believe our solution solves the problem for all but the toughest courses.

We have an inkling that there is still more work that can be done on this, which is why you haven't seen FIXED ALL MOBILE SAFARI CRASHING in neon lights within our release notes, but we've made significant progress.  If you have a .story project file that is still capable of crashing Mobile Safari, we'd love to have a copy of it so that we can continue to optimize our published output for iOS.

Hello, all.

First, I’d like to sincerely thank you for continuing to let us know how important this problem is to you. We cherish our community, and it’s forum threads like this one that really make an impact.

Second, I’d like to tell you a bit more about the root cause of the problem and what we’re doing to fix it:

Some Background

Storyline does two things to produce a speedy learner experience:

1. We quietly preload as much content as possible into memory while the learner is focused on the current slide.
2. We keep visited content in memory after the learner leaves the slide to support the back button.

In doing so, learners can confidently navigate in all directions throughout a course, knowing that whatever slide they need next is preloaded and ready to go.

The Problem

Our customers are great at producing beautiful, media-rich course content, but it’s no secret that Mobile Safari suffers from some memory management challenges. The preload approach serves us well on most devices and browsers, but as many of you have learned, courses with lots of media can crash Mobile Safari. This happens most often on older Apple devices, but even new iPads and iPhones can have trouble keeping lots of multimedia in memory, especially when other tabs or apps are open.

Our Solution

We want to make Storyline smarter about knowing when the browser can handle preloaded content in memory, and we’ve been working hard on logic that:

• Maintains the preload approach on every device and in every browser except Mobile Safari.
• Asks Mobile Safari for information on the age of the device and:
  • Depending on the weight of the slide, preloads some content if the browser can handle it and keeps some content in memory.
  • If the slide is too heavy or the device is too limited, preloads nothing and keeps nothing in memory after exiting the slide. Slides will load more slowly for learners in this scenario, but it should reduce the frequency of crashing.

This is a challenging solution to implement, mostly because of the limited information we get from the browser. This is especially true since iOS is so impacted by other open tabs or apps, about which Mobile Safari tells us nothing.

To make this happen, we’ve been digging deep into the sample projects that many of you have provided and testing them hard against our library of iOS devices in an effort to isolate the limits of Mobile Safari. It’s an inexact science, but we feel confident that we can solve the problem.

I can’t promise a precise release date for the above solution, but it’s super important to us. We have our very best minds working on the problem. We’ll let you know as soon as it’s ready, and thanks again for helping us make this a priority!

Is there anyone I can talk to regarding compensation for this fault? My company purchased Storyline 3 the moment it was released and after discovering this fault we have had to revert back to using SL2, as the HTML5/tablet output is the main requirement for our clients.

We feel a bit conned off for purchasing a product months ago that is not being used due to a fundamental flaw in how it works and lack of testing before release.

I understand this must be a big problem for your technical team but we feel it's only fair we are compensated. Please feel free to email me.

Thanks

Phil

Good Morning, James and Joanna.

James, this issue is newly-introduced in Storyline 360 because the HTML5 engine in Storyline 360 is a complete rewrite when compared to our HTML5 output from Storyline 2.  This has allowed us to expand our browser support, achieve 508/WCAG compliance, and accomplish feature parity.  Unfortunately, it also means that we introduced new challenges like this one.  We have a solution mapped out, and we're working on that now.

Joanna, I still can't project a release date, but we promise that this forum thread will be the first place we visit when our solution is ready.

Our company is seeing the same issue with Storyline 3 SCORM output crashing on iPad devices. We have some very high-priority projects where we are releasing first-time for mobile users, and the performance we're seeing is not going to provide a good user experience right out the gate... We need a fix to this yesterday...

Ditto on what Mark Wheeler said.  It's been 3+ months since this was first reported.  If there isn't a resolution then we'll (my company) have to revert back to using SL2 and not renew SL3...or explore other options entirely. 

Furthermore, there should be a huge disclaimer on SL3 stating that it has issues with iPad. Developers should be aware of this huge pitfall prior to production.  Long, expensive, and time sensitive projects are at risk that just can't be rebuilt in SL2 as an 'on the fly' backup solution. Articulate shouldn't sell a product that states it works on a platform when it doesn't...especially one as expensive as this. Perhaps have an 'export to SL2' feature on SL3 so there's a backup plan while this is being figured out.

I'm a fan of Articulate, but the ball has been dropped on this one.

Good morning,

I see there was an update yesterday for Storyline 3:
https://articulate.com/support/article/Storyline-3-Version-History

March 6, 2018 (Build 3.3.15007.0)

Among the fixes listed:
"Fixed: Lots of videos in a course could cause slides to lag or lock up in HTML5 output, and they could be sized or positioned incorrectly during preview."

Could you please confirm if the fix for "Lots of videos in a course could cause slides to lag or lock up in HTML5 output" is an attempt to resolve the main issue of this thread which is (quoted from Staff Ashley Terwilliger 9 days ago in thread) "crashing on mobile Safari due to the way Safari keeps the memory and what Storyline is trying to load"?

Thanks very much!

Hello! We have similar iPad issues with slides not advancing on SL360 Build 3.25.18088.0 when testing on SCORM Cloud (although this may be an issue on normal web link as well but we have not tested this yet). I've narrowed it down to 2 slides. First slide has about 20 layers, each with videos and orange buttons that advance to the next layer above. At the end of this first slide's last layer, we have a button that is supposed to jump to the next slide.

Instead, on the iPad anyways (not on PC testing), it freezes. The Menu (we call Course Map), does show that the next slide is active but the on screen slide does not update from slide 1 to 2 as it should.

I'd like to request any other options for troubleshooting and upload my file for the support team. I just opened a case report for this: 01733616. Thanks!

Hi there Patrick,

Thanks for posting here.  I know this has been really frustrating, especially since you already missed a deadline.  I can see you are troubleshooting with Abel in case 01064418, and he working with our Quality Assurance team to determine next steps. We'll be sure to keep you in the loop along the way. 

Has there been any update on this issue, it is starting to become a major problem, and a reason to not pick up any additional SL3 licenses.