04 Dec Refresh, reuse, recycle: Breathing new life into Flash-based learning with HTML5
Converting a decade-plus of Flash-based learning content into HTML5 assets presents a serious headache for many L&D departments. Failing to do it – or getting it wrong – risks losing years of great learning content and incurring significant costs developing new materials from scratch. Brightwave’s Solutions Technical Manager Nick Eastham looks at the background to this widespread problem – and how L&D teams can tackle it.
In the beginning of e-learning, there was Flash.
Flash was a digital multimedia platform for creating a huge range of rich visual experiences. From custom vector graphics to animations, browser games, and internet or desktop apps, if you needed visual or graphical assets to bring your e-learns to life, Flash (and a developer) would build it.
Thanks to Flash’s design scope, and its flexibility publishing to multiple desktop browsers, Flash became the invisible engine behind much of the rich visual media used in e-learning all over the world. And in its early versions HTML, the language that webpages are designed in, didn’t have the inbuilt capacity to support complex graphics and video, so you needed a platform like Flash to take care of those extra issues. But things change.
The post-web 2.0 take-off of mobile changed the game for Flash. The downside of its high-quality visuals translates into high usage of your CPU, which means if Flash is designed to run an animation at a resolution of 400×250, but the embedded player in the user’s browser is set to 401×251, Flash will re-size and re-render every individual frame before playing, which taxes the processing power of your computer. On a desktop or laptop with a bit of spare memory, this doesn’t cause a noticeable problem – but on mobile it means your device has to do a lot of work in the background to present Flash movies as they’re meant to appear, and this sucks the life of your battery.
This was one of the main reasons behind a single move that more than any other kicked off Flash’s death spiral – Apple’s decision not to support Flash on its flagship mobile devices – the iPod, iPhone and iPad. These devices and their imitators were and still are the signature consumer products of the early twenty-first century, and have shaped the trends in technology and user behaviour for everything that has come since, so a decision taken at the corporate level by Apple quickly became the default choice of the industry.
What does the end of Flash mean for e-learning?
Going forward, with so much of the web being built in HTML5 already, the short answer to this is probably ‘not much’ – new web based learning resources are built in HTML5, and we carry on as before. But that doesn’t look at the very real problem of legacy content.
There are hundreds of thousands of Flash assets sitting inside LMSs or other enterprise knowledge management networks, built over the last decade and a half. For the most part these are still useful learning resources – they still look good, they still meet learning needs, and their use- value to the learner is still strong. But what they significantly fail to do is meet the learner at their new, mobile point of need, and offer a similarly rich interactive learning experience on a handheld device that they would on desktop.
Junking these important assets, or ignoring them until they are truly obsolete, would represent a huge waste for Learning and Development. Similarly, the task of rebuilding them from scratch in HTML5 will involve redesign and redevelopment costs with real potential to spiral. The repetition of effort represents a serious inefficiency, and inevitably diverts important resources from other important activity.
In order not to waste these existing assets, a process of conversion will be necessary. But there are a few ways to be smart about this.
Many of today’s most popular elearning author tools, such as Storyline or Captivate, have anticipated this issue and in their more recent versions are able to automatically re-publish old Flash courses in HTML5 – so updating your old Flash resources might be as easy as re-opening the source in the latest version of the authoring tool and ticking the right box when you re-publish. This option might itself not be as simple as it sounds – your courses might have dozens of separate Flash assets integrated into them, each of which would need to be re-purposed and re-embedded in the course file. You would need to carefully consider which format to convert these Flash assets into.
If your course wasn’t originally built in one of the more adaptable authoring tools, converting Flash files to HTML5 can leave you with a more difficult problem which might require some serious effort to solve. Having worked on several solutions where this was in fact a necessity, I have developed a few guiding principles that can inform your process towards the right solution for you:
Draw a clear content map of your existing Flash assets. Know what you’ve got, how it holds together as courseware, and what you most need to retain/convert. Also take note of the original learning need and its importance to your current strategy. Make sure you know the technical specs and tools used to build the original course.
What do you need to do to your legacy assets to meet your current learning needs? Do they need to be redeployed for mobile only, or turned into truly responsive files that render perfectly against any screen type or orientation? What browsers, platforms and functionality do you need to retain or rebuild to, and which can you afford to let go? Which tools or expertise will you need to complete the conversion process?
Draw up a roadmap of activity that puts your immediate needs first and, depending on the size and number of your legacy Flash-based e-learns, allows for a long-tail process of gradual conversion and re-adoption.
As discussed above, the conversion process may be simple if you have the right tools and legacy materials in place – or it might be a much more involved process. Even if you are in the lucky position to be able to convert via an up to date version of the authoring tool you built the original files in, there are still extra considerations you will need to understand in order to get the right kind of output to fit your course architecture.
This can involve a process of trial and error, or it can be solved with a little bit of expert knowledge. Here at Brightwave, we have largely avoided the problems around designing rich, responsible visual assets for mobile by developing our own HTML5 authoring platform WaveForm.
While working in this space we’ve developed a lot of tips and tricks to help negotiate all the myriad challenges Flash-HTML5 conversion presents. We’ll be sharing some of this knowledge with you in the coming days, and if you have any questions – feel free to send us an email or use the comments below!
Follow Nick on Twitter.