What to Expect When Converting Flash to HTML5
Check these questions and answers before starting to convert Flash to HTML5. This article was originally posted at blogs.adobe.com. About the author: Michael Hu is a senior product marketing manager for Adobe Creative Cloud. Michael’s background includes working in product management, product marketing and business development on a broad range of initiatives such as web hosted services, mobile and desktop software, gaming, and customer care support offerings. Image courtesy Photonphoto via Bigstockphoto.
We had the pleasure recently of connecting with interactive software engineer Joseph Labrecque to learn more about his thoughts on Animate CC, converting Flash to HTML5 and what type of content should be converted.
What do you do?
I’m involved in a lot of different things. My primary role is that of an interactive software engineer for the University of Denver in Denver, Colorado. I also run a small business called Fractured Vision Media, LLC and have a number of other activities I’m involved with from teaching Animate CC and other Adobe applications for University College to speaking for major events like Adobe MAX. In addition, I’m continually involved in the production of video courses for Lynda.com, Pluralsight, and others – and occasionally author books on Animate CC and related subjects.
Why would someone want to use Animate CC?
Animate CC is in a unique position among creative applications as it is an environment through which an individual can, within a single application, perform both design and development tasks with ease… simultaneously. This means that those individuals who only do design work, or those who are only interested in code, can augment their existing skill-set by exploring the “other side” in a way which is easily accessible to them. I’m a perfect example of this in that I originally approached Animate CC (via Macromedia Flash) as a pure designer with no interest in code whatsoever. Through exploration of the tools available and an interest to expand into areas of interactive media, I was able to learn to program in small steps by relating the aspects I was unfamiliar with (ActionScript) with those I was rather deeply familiar with (design and animation). Today I’m a software engineer in title and position but remain a hybrid creative/interactive in truth.
Most people understand that both HTML5 Canvas and Flash Player content can be created with Animate CC – but some seem to still be confused… thinking that we can only produce content for HTML5 Canvas or only for Flash Player. Animate CC is a true multi-platform content creation tool and what many do not realize is that we are not even limited to the two platforms mentioned previously – but can also produce content such as animated GIF, HD Video, SVG, WebGL content, and more. One set of platforms that is criminally absent from the minds of most casual users are those which can be targeted through Adobe AIR: Windows and macOS for desktop, Android and iOS on mobile, and even Google and Apple TV hardware. Very powerful!
When users are considering converting Flash content to HTML5 what should they consider?
The first thing to consider is the project itself – what sort of content are we dealing with? How old is it? Can the features and qualities of the project be replicated through native web technologies? If it is an animation then we can easily convert internal animated content and assets from one document type to another using Animate CC. We could even copy specific assets or layers from one document to another. Animation is really quite straightforward. What gets tricky is when there is some sort of interactivity involved – especially if there is a lot of ActionScript code. I’m a believer in recognizing the original purpose of a thing and making intentional decisions based upon considerate thought and future projection in light of past experience. Does the project in question, assuming it has some age behind it, fulfill its original purpose – even today? If the answer is “yes” – then we don’t need to really do much of anything. If the answer is “no” – then a decision must be made on whether to convert the project, rewrite it entirely, or kill it outright. If the answer is “yes, but…” then we have to perform some projections based upon all the data – and that is a much more difficult decision because it involves unknowns and a certain amount of intelligent guesswork. When considering older Flash-based content – we find that all of these scenarios are valid.
What type of projects are easy to convert?
Just about all animation (timelines, tweens) and assets within a document that was previously targeting Flash Player should convert almost perfectly with the exception of certain unsupported filters and effects, differences in how text may be handled, and so forth. Additionally, content such as web-based ads or basic infographics will convert wonderfully – though if there is interaction involved, the ActionScript code must be converted to JavaScript in order to target the native web. Thankfully, the code for basic interaction is very similar between the two languages and Animate CC even comes with a variety of code snippets you can use to wire up common tasks with ease.
Does it make sense to convert legacy Flash content to HTML5?
It truly depends upon the project size and the features of Flash Player it takes advantage of. Think also of the time in which we now live and measure where we are against both future and past: is the application a product of its time? Much that was written 5 years ago will likely look outdated and a complete rewrite with today’s technologies in mind will often make more sense than a simple conversion of assets and functionality from one platform to another. I do believe that a lot of content can be converted quite easily though, considering how much animated and interactive media exists in the world after so many years. I mean, Flash truly was KING for an awful long time and much of that content is animated – or includes the simplest of interactivity. These projects can exist across various platforms without a whole lot of hassle. I’ve actually opened up some small interactive games and experiments in Animate CC written well over a decade ago targeting Flash Player and most of the code is easily translatable to JavaScript – especially the stuff written in ActionScript versions 1 and 2. In terms of those projects which are animation-only… it’s so simple to convert these animations to either HTML5 Canvas or export them to straight video playback.
I do believe in preserving all of the great historical content that exists on the web today as older Flash .swf file content though – it’s hugely important to preserve this material. The preservation can be done in many cases by converting Flash Player content to HTML5 Canvas or even straight to video using Animate CC’s precise video export capabilities. More interactive content will require conversion of the code – while massive games and other complicated projects likely will simply exist as they are to be accessed through Flash Player or some future runtime capable of dealing with such content. Regardless – Flash Player is still supported across desktop browsers and Adobe does update the runtimes regularly with quarterly feature bearing releases… so legacy content will continue to run just fine for the foreseeable future.
When converting Flash to HTML5 should the user expect everything to convert or should they expect to do some clean up of the code?
Any ActionScript code that is present will by necessity have to be converted to JavaScript to run in the native web. Fortunately, for most projects, this is something that can be done fairly easily if you have an understanding or either language as both JavaScript and ActionScript are both dialects of the ECMAScript language specification. Most interactive content can be handled in this way.
There do, of course, exist other projects which are not ideal for conversion. For instance, I’ve written a number of incredibly video-centric applications targeting Flash Player which make use of RTMP video streaming protocols and additional APIs that exist on Adobe Media Server or something that relies upon BlazeDS data transfer protocols and methods. Functionality such as this is so reliant upon these other servers and services – and differs so wildly from what is pobble or manageable on alternate platforms that a simple conversion in Animate CC simply won’t cut it. The assets and user interface would convert just fine but we’d have to then explore additional technologies to augment what we are left with after the conversion process. While I’m sure there are many 3rd party libraries and additional servers that exist for performing similar functionality… this scenario would basically include a full-scale rewrite of the project. Luckily – most projects out there are no where near this level of complexity!
Additionally, much Flash content exists which is built upon the Apache Flex (formerly Adobe Flex) framework. Flex takes a different approach to design in that it is a platform which can combine MXML and visual content produced in Animate CC with ActionScript 3.0 within an external development environment like Flash Builder, JetBrains IntelliJ IDEA, or even Visual Studio Code from Microsoft. Since Flex projects are not based within Animate CC documents, the normal document conversion mechanisms present within Animate CC spoken of previously do not apply. However, contributors at Apache Flex have been building an alternate version of Flex branded as “FlexJS” which exists to solve this same problem. With FlexJS, you can write your content using MXML and ActionScript 3.0 and when ready, compile it to target both Flash Player and the native web browser through a process which converts the code into standard web technologies as HTML and JavaScript (very similar to how TypeScript is converted to JavaScript in Angular projects).
No matter what your approach is to existing Flash content – there is always a choice to be made and with the evolution of tools and frameworks at hand today… conversion really is possible at all levels if that is the desired route.
