Some time ago I wrote a blog about what the Death of Flash means for e-learning developers. It proved to be one of the MOST popular posts I've ever released, and in the days that followed I received many emails from appreciative readers. But almost all of these respondents wanted to know the answer to the same question:
"What is the recommended process for converting existing SWF courses over to the new mobile-friendly HTML5 format?"
This blog post is an attempt to provide at least SOME guidance on this very timely topic. However, I fully expect the steps I outline below will EACH require far more detailed treatment and explanation in future blog posts.
Step 1: Decide if this course should really be replaced instead
I submit that, BEFORE you embark on any of the following steps related to assessing requirements for conversion to HTML5, you should sit down with your client or management and seriously consider whether the age of the course, or the amount of now redundant content, would mean spending any time or money on it would be pointless.
If the answer to that question ends up being YES, it's better to 'bite the bullet' now, retire the course, and develop a new one from scratch.
Step 2: Decide whether to develop Responsive or Normal HTML5?
Responsive HTML5 courses dynamically re-size and re-format the content in response to the screen resolution of the end-user's mobile device and its orientation (Portrait or Landscape).
When managers hear about this bizarrely useful behavior, they typically think responsive must be the Holy Grail of all e-learning, and promptly see it as a 'no-brainer decision'. What they don't usually realize is that Responsive HTML5 has a number of serious downsides.
It's either responsive OR normal, not both
For one thing, deciding your SWF courses must be responsive effectively obligates you to rebuild them again from scratch. This is because Adobe Captivate does not allow courses previously developed as SWF to be published out as Responsive HTML5. Most Captivate users don't realize that responsive project files have significant structural differences to a normal CPTX file. The bottom line is, you can have a project file that publishes out to Responsive HTML5, or you can have a project file that publishes to both SWF and HTML5, but you cannot have all three formats from the same CPTX file.
Responsive costs more to build
Another issue with responsive projects is that they can take a lot longer to build and place many more limitations on what you can include as far as functionality. The extra time gets eaten up due to the fact that responsive projects need to be designed for anywhere from three to five different screen sizes. For example, take a look at the screenshot below from a Captivate 9 responsive project.
Instead of just arranging objects for a single slide (as in normal projects), responsive projects require the designer to reposition and reformat those same objects for each and every separate view-port size. That translates out into a lot more time and money. (This probably explains why the survey I've been conducting from this website shows less than 10% of participating Captivate developers chose responsive HTML5 as their main project output.)
However, an important issue for Captivate developers is that when managers make the decision to go responsive, most are totally unaware of the fact that their training budget will build far fewer responsive courses than normal ones, or of the fact that changing their mind later to return to normal projects means ditching their responsive courses already built. By the time they find out, it's usually too late.
So part of your job as the 'e-learning expert' on the team is to make sure all the stakeholders are well educated about these issues before they can make a mistake and blame it on you.
NOTE: Every suggestion after this point involves making fairly radical changes to the Captivate project files. ALWAYS be sure to save a backup copy of the CPTX file in case things go horribly wrong. You should also ideally be using the very latest version of Adobe Captivate to do any of this.
Step 3: Decide which specific screen resolution/s to target
Let's assume for the moment that you have decided the course content is worth saving and that you do not need to consider developing a Responsive e-learning course. So, there remains at least a possibility you can do some minor or major surgery on your existing CPTX project files to make them HTML5-ready. So far so good.
The next issue to consider is whether or not the current project height and width needs to be altered to better accommodate the needs of the technology your particular target audience will be using to view the content. I'm listing this decision at this early stage because I know from experience even minor changes to project dimensions can have a huge impact on course content. So you really need to know very early in the project whether or not you can avoid this pain.
Locked-down corporate environments
If you are building for a corporate environment where everything is pre-defined and 'locked down', this decision may be relatively simple. In an ideal situation, your target audience may all be using the company mandated operating system, standard issue flat screen monitors, and default web browser. Additionally, your management is not interested in supporting mobile devices.
If so, that pretty much solves your target audience issue, and will usually mean there is no need to consider reformatting the course dimensions. E-learning courses don't need to fill the user's entire screen. They just need to play at some size that falls within the borders of the screen resolution.
Desktop users are the easier ones to accommodate for HTML5 conversions because their browsers can easily stretch or shrink to fit the course content. Most desktop or laptop users are now running screen resolutions well in excess of 1200 pixels wide, and the majority are likely to be running resolutions of 1920 or more.
If you don't believe me, take a look at the screen capture at right taken from my own Google Analytics report showing screen resolutions for Infosemantics.com.au visitors over a single 24 hour period. Note that the most common resolution by far is Full HD 1920 x 1080. But almost all of the people were using resolutions above 1024 pixels. (Goodness only knows why 152 people turned up with older mobile phones at 360 x 640 resolution screens.)
What this all means is that targeting desktop users will almost never require changing the project height or width of an older e-learning course because the content will normally be far smaller than the screens being used to view them.
If you MUST support mobile devices...
The situation becomes much more complex the moment you are obligated to support mobile devices as well as desktops because it's quite common to find mobile screen resolutions will NOT be able to accommodate the height or width of existing course content. (Yes you COULD just change the display dimensions in the HTML file to make everything fit, but that will usually cause significant loss of visual clarity, especially when it comes to reading on screen text. This is usually not the best option.)
So how should you approach this challenge? First determine the smallest view screen size you are required by your client or management to support. How would you find this out? Do research! In corporate environments it's quite common for the IT department to run 'auditing scripts' as a normal part of each user's login procedure. If you are on good terms with the IT department, and they actually do these types of audits where you work, then they may be able to give you a report that shows a breakdown of all screen sizes being used across the organization at login, including those of any mobile devices being used to access the system.
If this is not possible, and your current courseware is being served from an LMS, check with the LMS administrator as to whether the system captures any 'analytics data' about the end user's technology of choice. For content being served from a normal web server, it should be possible to have the website administrator set up Google Analytics to gather data on end user device resolutions. (Google Analytics will even break down the results to show you which specific mobile device models were used to view your content.)
Before you make another possible mistake...
Before making any irrevocable changes to project file dimensions, I strongly suggest you first do up a prototype of content at the mandated size and have your client or managers actually view it on their own systems. They may not like what they see when confronted with the outcome of their decisions, leading them to reconsider. (I have found that managers are quite petrified of making mistakes and appearing incompetent before their peers. They will usually be grateful that you saved them from making a blunder.)
In any case, you must know the final dimensions of the published content, because this will determine the final dimensions of the CPTX files, and that is likely to determine lots of other things about placement of objects on slides.
If it becomes necessary to alter project file dimensions in Captivate, this is done via the Modify > Rescale Project... menu option. When you do, I recommend you deselect the option that automatically rescales the screen objects as well as the slides (as shown in the screenshot at right). In practice I find that leaving this setting on results in a lot more re-formatting work to get everything to look right again.
Step 4: Eliminate all non HTML5-compliant components
Building for HTML5 means your course cannot contain any component that would not work on a mobile device browser. This is the part most Captivate developers think they can easily handle, but you may be surprised to know the list of potential non-compliant components is quite long, and they're not all obvious candidates for removal.
Remove all Flash SWF animations and SWF graphics
You will have known by now that all animations created in Flash and imported into the Captivate project as SWF need to be removed. But it has also become a common (though not recommended) practice to capture software simulations in Captivate, publish them out as SWF files, and then insert these into another CPTX project file. All SWFs have to go, regardless of where they came from.
To discover at least some of the SWF components that infest your project file, you can start by looking in the Project Library (shown in the screenshot at right).
For example, note that the Media section of this Library lists quite a number of SWF files used in the project. The Video section below it also contains an FLV file. (More about FLV below.)
SWFs aren't necessarily animations. Some graphics editors allow you to save a static graphic as SWF format. Though the original PNG or JPG file would be HTML-compliant, the SWF version of the same file would not be.
No matter whether the SWFs were originally created in Adobe Flash, Adobe Captivate, or some other application you need to replace them, because they won't work in mobile browsers due to the fact that none of them have a Flash Player plugin.
Remove PowerPoint-based slides
This one is going to hurt big-time if you happen to be one of those e-learning developers accustomed to building their course content in PowerPoint and then importing that PPT deck into Captivate. The fact is that Captivate converts these slides into...you guessed it...SWF animations.
The screenshot at right shows the Properties data for a slide in a Captivate project created directly from a PPT deck. Note that the background of this slide is shown to be an SWF file. (If the original PPT slide contained animations, the SWF background for this slide would also be animated.)
The fact that PPT slides become SWFs is the reason Captivate disables the option under File > Import > from PowerPoint slides in any responsive project. Yes, that option still exists in normal projects to allow publishing to SWF. But when you publish out to HTML5, the background SWFs are converted to static PNG files instead.
So unless you are happy for all of your HTML5 courses to consist of little more than frozen background images, you need to forget about using PowerPoint from now on and build everything from the ground up in Captivate, using only supported slide objects.
Change SWF Pre-loaders to Animated GIFs
Did you know that Captivate's own pre-loaders (specified in Preferences > Project > Start and End > Preloader) are actually SWF files? Note the default.swf preloader file in the screenshot shown below from a project that was originally created in Captivate 6.
Captivate does offer a selection of animated GIFs as alternative pre-loader animations, but be aware that these don't offer all the same functionality as the SWF pre-loaders. They mainly give you something to look at while the project loads up.
Change SWF project skins to HTML5 skins
Project skins from older versions of Captivate were also usually SWF. To play safe, reset the skin to one of the defaults provided in the latest Captivate version that can publish to either format. That skin is more likely to have an HTML5 equivalent.
Remove or convert all FLV Videos
In the days before Captivate had Video Demo and the CPVC capture format, all full-motion video captures in software simulations were saved as Full Motion Video or FMV format. This format is also not going to work in HTML5. You will either need to remove these components or else convert them to a more compliant video format such as MP4.
Remove all AS2 or AS3 Widgets
Since Captivate 4 it has also been possible for ActionScript programmers to build SWF widgets and insert these into projects to enhance and extend functionality. In very early examples, these may have been built with ActionScript 2, but since Captivate 5 arrived, only ActionScript 3 widgets could be inserted. Either way, all such SWF widgets must be removed. (Don't bother even looking for HTML5 equivalents for these widgets. Most widget developers gave it up as a bad idea.)
While on the subject of widgets, you may not have known that Captivate's Text Animation objects are also SWF widgets. So you need to remove them or replace them with static text captions instead.
Captivate's Learning Interactions are also widgets, but those that ship with the latest versions of Captivate should be HTML5-compliant. If in doubt, replace them with current versions.
Remove rollover objects
In the mobile world, where there are no computer mice and everything is done with your finger or a stylus, rollover and rollout events become redundant. And that means Captivate objects such as Rollover Captions, Rollover Images and Rollover Slidelets also have no place. Remove them or replace them with Advanced Actions based on click or tap events.
Remove slide transitions
And one last thing...you need to remove all slide transitions. Those nice fades or wipes effects when moving from one slide to the next are all based on (you guessed it) SWF animations, and are therefore not compliant with HTML5 output.
Using the HTML5 Tracker
To be fair, Adobe saw this issue coming several versions ago and kindly included a tool called the HTML5 Tracker that is designed to show Captivate developers all objects or elements in their project that would be unsupported in HTML5 output.
For example, in the screenshot at right you can see that it lists unsupported objects under the slides on which they can be found. Scanning the list you will see many of the objects we have discussed above, including: Text Animations, Widgets, and Slide Transitions. But the tool isn't perfect.
You cannot trust the HTML5 Tracker to find every single issue for you. And unfortunately it has sometimes given 'false positives', reporting something as unsupported when in fact it is. (For example, the HTML5 Tracker in Captivate 8/9 reports several supported Effects as unsupported.) All things considered though, it's still a great place to start.
Step 6: Keep HTML5 modules as small as possible
I'll make this the last one short, not because there's nothing else to consider, but because this blog post is already far too long...
Once you have removed all non-compliant elements from your project file, it's time to consider what you have left and decide whether or not it's too heavy to play well on a typical mobile device. Yes, that's correct...just because your beloved course played perfectly well on a desktop or laptop DOES NOT MEAN it will do the same on any mobile device.
This topic alone really deserves an entire dedicated blog post to explain, but in brief here is the issue...
Mobile devices are far less powerful than even a mediocre desktop or laptop system. Their CPUs are usually slower, they usually have less available RAM beyond what the operating system needs, and their web browsers have minimal caching capacity (that's where they store web pages you have already visited).
The situation IS getting better every year, because newer mobile devices are progressively more powerful. So the problem will eventually go away. But there currently remain many scenarios where even small multimedia e-learning courses are capable of bringing a typical mobile device to its knees.
Now on a typical desktop system all you would experience is that things get slower. But on a mobile device, when resources become scarce, the operating system goes into self-protect mode and starts shutting down any non-essential applications to claw back valuable resources. Guess what...the mobile web browser in which your course is running will not be regarded as more important than anything else that needs resources. So browsers are among the first apps to get shut down when things get tight.
And in case you are thinking this will only be an issue for courses with hundreds of slides, think again. I have known mobile browsers to crash within less than 10 slides. It all depends on the device in question, and the course in question.
The bottom line here is that the desktop world will allow you to get away with far more than you can in the mobile world. And in HTML5 generally, the rule is always "less is more".