The release of Adobe Captivate 7 has introduced a number of new features and even more updates/enhancements. There is an obvious emphasis on mobile. With this review, I’m deciding to comment/critique Captivate 7 from a mobile-oriented viewpoint. I won’t be commenting on the host of features that benefit all mediums (like Shared Actions, Tin Can integration, Interactions, etc.). If you’re interested in all the features of Captivate 7, check out this page.
Ease of Use
One of my favorite things about Captivate 7 is how easy it gets people into mLearning development. mLearning can be extremely complicated and many of the concepts reach outside of instructional design and into front-end development (i.e. responsive design, UX design, HTML/CSS development, etc.). These concepts inhibit experimentation and can be discouraging.
With Captivate 7, the majority of interactions and Captivate objects are HTML5 compatible. This means, Captivate developers can publish existing content to a format viewable by iPhones, iPads, and other mobile devices. Plus, new interactions were added (or updated) so developers have more options for displaying information. You may realize one interaction has better usability than another on a tablet. The more options for interactions, the better your content will look.
I’ll admit I don’t get excited about Interactions like Hangman, Hourglass or the Memory Game. They are fun, but I don’t foresee myself using them. I am, however, extremely excited about two interactions in particular: The YouTube interaction and the Web Object interaction.
The YouTube interaction allows you to embed a YouTube video inside your course. This is vitally important because delivering video to mobile devices is extremely difficult. Not only do you need to support multiple codecs (H.264, WebM, & Theora), but you also have to consider bandwidth. With this interaction, YouTube takes care of it for you. YouTube will server your users the correct format and use dynamic streaming to tailor the bandwidth of the video to the devices connection speed.
I’m also excited about the Web Object interaction because I can now embed remote web applications inside a Captivate project. The Web Object interaction uses an iFrame to embed a remote page. This allows developers to include an external website (i.e. Company website or Google Map). I’m excited by it because I can develop more complicated interactions or remote content utilized by multiple Captivate projects.
One final note on the Web Object interaction: A few mLearning experts have complained that Captivate missed the ball with responsive design. I agree that we need to be thinking responsively and a tool like Captivate should have responsive features. This gets complicated, though since not every subject matter expert is ready to be a responsive web designer. With the Web Object interaction, however, developers who are ready for responsive web design can use a tool like Edge Reflow, Muse or Dreamweaver to create responsive content and embed them directly on a slide in Captivate. Full disclosure: There’s a little CSS work required to do this (see below in my critiques section).
Adobe Captivate App Packager
One last feature I want to discuss is the Adobe Captivate App Packager.
This tool does two main things:
- Allows you to embed Edge Animate or other HTML5 content on any slide in your project.
- Allows you to package your Captivate content as a native iOS or Android application.
The first point’s appeal is pretty obvious. If you are making mLearning content and need a fancy animation, Captivate can be pretty limiting. Edge Animate, on the other hand, is a great HTML animation tool. The Captivate App Packager will let you select that Edge Animate content and embed it in your Captivate project.
The second point is the fun one. The Captivate App Packager takes your content and sends it to Adobe’s PhoneGap Build service. PhoneGap Build creates native (mobile) versions of your project and gives you a link to download them. When I first tested this, I took an existing Captivate project and had a mobile application on my iPad in less than two minutes (seriously, I timed it). Now, it’s not perfect and there are some concerns (noted below), but this feature does some really good things. The main benefit is it gives Captivate developers an easy way to start experimenting with mobile development. This means companies can quickly assess the work involved in migrating their eLearning to mLearning.
Room for improvement
As with any software upgrade, certain things may be overlooked, developed incorrectly, or simply left out. There are a few things I wish Captivate 7 did, and a few others I wish Captivate 7 did better.
Mobile UI issues
I would love to see some responsive design features added into Captivate. This gets to be extremely complex so I understand why they aren’t there. But allowing developers to turn on a single column mode and have content adjust accordingly would be nice. At very least, remove the inline styles in the HTML wrapper so developers can override styles by simply including their own CSS file. Outside of that, it’s the little things (and I mean that literally). Buttons in the control bar and Interactions need to be bigger and more responsive. The minimum button size should be 44 x 44 pixels and currently the Captivate control bar buttons are 20 x 20 pixels (way too small for a finger). Finally, an issue with the HTML wrapper is that it has a maximum-scale=1 in the viewport meta tag. This removes the ability to pinch and zoom the content and also disables assistive devices from optimizing content to the user’s needs.
File Size & Requests
In a simple test, I noticed that a 62KB JPG image I imported ballooned to a 612KB PNG when published from Captivate. This appears to be because the HTML5 publisher converts JPGs to PNGs. There may be some internal reasons for that, but I’d like to see some consistency there. On the other hand, I tested an existing project that published an SWF with a size of 22MB and the HTML5 equivalent was actually 19MB. So I was pleased to see cases where the HTML5 version is smaller.
PhoneGap Build Concerns
As I mentioned above, I absolutely LOVE the PhoneGap Build integration because of its ease of use and seamless workflow. However, I have two concerns. Both of which the Captivate Team doesn’t have much control over.
Firstly, setting up the mobile workflow for iOS involves being in the iOS developer program, purchasing a certificate, and provisioning devices. I’ve blogged about this process and it’s a lot of work to set up. Content developers need to be aware of this and might need help setting up their workflow. In my opinion, this workflow is really only for in-house app development not for applications destined for the iTunes store. Apple’s rigorous rules about what goes in the iTunes store will be difficult to adhere to with a tool like Captivate. My last concern about this feature is PhoneGap Build limits the project size to 10MB. Earlier, I mentioned the 19MB published project I was testing. This was 40 slides with audio. So if you want to use PhoneGap Build (and have audio in your project), you’re looking at roughly 20 slides maximum (this is of course a huge estimate since slide duration and other assets can affect size too).
I most definitely recommend the upgrade to Captivate 7. When you add the rest of the new features/enhancements to the mobile features I covered above, there are plenty of reasons to upgrade. The mLearning space is evolving at a rapid pace and the Captivate Team is responding with tools that developers are asking for. There are some weaknesses and areas needing attention, but the key is that Captivate is moving forward and giving us the means to do the same.