A popular request in 2012 is converting Adobe Flash animation and graphical interactions to HTML5. Approaches and information on how to do so is constantly changing and evolving. The team at Jibwa LLC in Tucson has been working out this issue for various projects for years now and have some thoughts to share with other engineers, marketers, and strategists looking to accomplish this feat of technology the right way.
In most cases there is little to no chance this conversion will be exact, and the reality is the conversion will be costly and many items may end up on the chopping block. There are strengths of Flex/Flash that are very weak in HTML5 and the team will have to work around them. Chances are the new HTML5 version will look the same or worse than the Flex/Flash version, but there is a possibility of taking the experience to vastly improve your presentation in other, more important ways.
Once the new cross-browser cross-device HTML5 baby is born you can rest assured you are not alienating anyone from your product, service, business, readership, etc. The new HTML5 version should have updates and considerations for retina displays as well as small screens and touch interaction. Further you can make graphic updates and keep your old flash version and use that on older desktop browsers. This means the HTML5/Flash hybrid is going to look great to 99.9% of your audience which is pretty amazing.
First and foremost: Understanding the limitations of HTML5 and having cross-device and cross-platform solutions is key. Here are some tips and considerations to help determine viability and approach to this sort of solution.
- HTML5 canvas based solutions won’t work on most devices. Don’t count on the canvas element if the end product is going to be public facing.
- CSS3 animations are way more efficient but also pose the same problem as canvas elements, they don’t work on most browsers, even modern ones.
- Javascript animations using elements and DIVs with background images are probably the best choice to reach all browsers (back to IE 7). This creates a lot of limitations in terms of efficiency but solves the problem with the least amount of headache and largest reach.
- Use loaders and sprite sheets for everything. On mobile devices this is especially important.
- Think about retina displays and start at those resolutions with your sprites sheets. You can always scale them down for performance. Also note that there is maximum image sizes on some Web-kit / iOS devices (even the retina displays that create the need for maximum resolution!) .
- Before getting started consider the impact of touch displays on interaction and animations. If you have hover interactions get rid of them or create a solution that appears on touch devices only.
