How to Avoid the Flash Dance: Planning for the End of Flash-Based Content

Similar to when two people divorce, the signs of a long and previously good technical pairing coming to end are often apparent to everyone before the actual news breaks. So the recent buzz about most of the major browsers developing exit plans from supporting Adobe Flash leaves many in the content world surprised it took this long.  Flash, at its prime, provided that essential tool for creating sexy content, complete with animated dance moves and complex hot spots. The storm clouds started gathering around 2008 when Apple chose not to support Flash on its mobile products, and it has been a slow and steady demise ever since.

Those of us who create online learning have been avoiding any use of Flash for years, and websites that are set up for viewing on mobile devices have dropped its usage as well. But what about training content created in older versions of authoring tools? That content was specifically intended for desktop or laptop viewing, and those tools published the content in Flash, often within a SCORM wrapper. Will these courses continue to work?

In short, no. When the browsers get to the point where they simply will not play Flash, those courses will no longer work. The format of the content will have outlived the browsers meant to play them.

So what options do we have?  I’ve outlined a few below.

  • For content created natively in Flash and for which you still have the source files (FLA format), some of these can be re-published in HTML5 using more recent versions of Adobe tools.  However, I would recommend careful regressive testing in case something that functioned before no longer functions quite the same way, as most complex interactions will not convert automatically. The older the Flash content is, the lower the chance it will convert well.
  • For content created in legacy versions of authoring tools (including versions of Adobe Presenter, Articulate Presenter, and Captivate before they had HTML5 output capabilities), the same technique applies: locate the source files, purchase a more recent version of the tool, re-publish, and test thoroughly.
  • Having worked in the custom content industry for many years, I know that many companies have lost the source files. If you still have the published files but no source files, it takes a much more technical person with a special set of tools to “crack open” a compiled Flash file and extract its assets (like text, images, and video). But it can be done. In cases where the source files aren’t available, re-building the course from a published file is often the only way to go. The course is re-created and often updated with fresher content as part of the process.
  • There are some Flash-to-HTML5 conversion tools available, such as SoThink or Swiffy. For basic Flash interactions, these tools work well. However, for long courses in which a SWF has been placed on individual pages, it is a very tedious process to convert the SWFs then update the HTML pages in which the SWFs were referenced. Although the conversion itself is easy, updating the files is not for the novice poking around in published files for the first time. The other drawback is that edits cannot be made; it is a straight conversion process. Many interactions simply cannot be converted this way.

The major browsers are taking intermediate steps to ease away from Flash, such as triggering a pop-up that requires the user to click before a Flash file will play. This lowers the security issues that have triggered this decision; however, the extra clicks add confusion to for users new to interacting with content. But eventually … and it may be a while yet … all support will stop. And those with Flash-created content without a strategy will be left scrambling.

If you have more questions, contact Tribridge. We have consultants who specialize in these kinds of conversions who can advise on which option may be best for you! Learn more about our Content Solutions.

Next Post