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 had ever published, 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 topic.
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: Develop Responsive or Non-Responsive HTML5?
Once you remove SWF from the equation, the only viable publishing format most Adobe Captivate e-learning developers will be able to consider is going to be HTML5 output. But that still leaves the decision of whether to just publish to Normal HTML5 or Responsive HTML5 and even then you now need to consider which of the two different responsive formats to use (Breakpoint or Fluid Box).
For those unfamiliar with the term, responsive content dynamically re-sizes and re-formats 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’ to go that route. What they don’t usually realize is that Responsive HTML5 has a number of serious downsides that need to be understood and factored into the equation.
Going responsive is a one-way street
If your organisation decides they want all courses to be responsive this will usually require rebuilding them again from scratch. Adobe Captivate does not allow courses previously developed in SWF to be simply re-published out as responsive HTML5. Most Captivate developers also don’t realize that responsive CPTX 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 normal HTML5, but you cannot have both formats from the same CPTX file. You can take a non-responsive HTML5 CPTX and convert it to responsive, but once you do there is no way to re-convert it back to non-responsive again. It’s a one-way street once you go responsive.
Responsive courses cost 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 (if you go break-point responsive). Instead of just arranging objects for a single slide (as in normal projects), responsive projects require the designer to configure the output so that those same objects can look good on devices using vastly different view-port sizes and orientations. That translates out into a lot more development time and budget. (This probably explains why previous surveys I’ve conducted from this website show only a minority 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 non-responsive projects is simply not an option because it means ditching the responsive course/s already built. By the time they find out it’s not really what they want, it’s usually too late.
So part of your job as the ‘e-learning expert’ on the team is to make sure all stakeholders are well educated about these issues before management 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 and is comfortable for the viewers.
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×1080 pixels (i.e. full HD) or even higher.
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 several years ago. Note that the most common resolution by far was Full HD 1920 x 1080. But almost all of the people were using resolutions above 1024 pixels.
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 phones...
The situation becomes much more complex the moment you are obligated to support hand-held mobile phones as well as desktops and tablets. iPads and other similar tablets nowadays have screen resolutions that rival or even surpass many desktops and laptop PCs. But it’s quite common to find mobile phone 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 not usually save your bacon because many interactive elements such as buttons or links simply become too small to be easily usable and your target audience will likely start to complain about usability. So 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 Captivate Library lists quite a number of SWF files used in the project. The Video section below it also contains an FLV file, which is a Flash video format.
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 no mobile device now has a Flash Player plugin. Any SWF content will show up as blank.
Remove any slides based on animated PowerPoint 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 animations into SWF animations.
The screenshot at right shows the Properties 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 usually SWF files? Note the default.swf preloader file in the screenshot shown below from a project that was originally created years ago 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 and do not really enhance the pre-loading functionality.
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.)
Remove all Animated Text objects
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.
Remove Rollover Slidelets
These objects are actually SWF-based and therefore not compliant with HTML5. There currently is no direct HTML5 equivalent object.
Replace any SWF Learning Interactions with HTML5 equivalents
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. So, unless all of your users will be viewing your content on a PC or laptop, remove rollover objects and 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.
Use 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 reports several supported Effects as unsupported.) All things considered though, it’s still a great place to start looking when converting SWF content over to HTML5.
Step 5: 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”.
