The eLearning Blog, SkillQ Advisor.

With the recent release of Adobe Captivate 5, the options for using video in eLearning projects have greatly expanded. In previous versions of Captivate, instructional developers were able to include flash video, but this decision presented several issues:

• Slide synchronization was questionable, at best
• Playback location was limited, and
• Playback controls (called “skins”) were required on our video unless we wanted our learners to endure our video at the default 50% volume level.

For video-loving developers, this was a frustrating path.

Captivate 5 now provides two methods for adding video. Each method has pros and cons, depending on your workflow.

1. There is the traditional insert procedure, performed by selecting from our menu: Insert > FLV or F4V File (although in previous versions of Captivate only .flv files were accepted so it read “Insert > Flash Video”).
2. New to Captivate is Insert > Slide Video, which provides some exciting new functionality.

Unfortunately, the Slide Video option does not become a one-stop video-inserting solution; we still need Insert FLV to achieve certain capabilities. So how do you know which one you should use? I’ll go through the following simple questions to help you determine which option you should use for a given circumstance. Keep in mind that to achieve the functionality, look and feel you want, you might use both options within the same project. Knowing the capabilities and limitations of both methods gives you the greatest flexibility in your development, and will undoubtedly save you from a few headaches.

Is the video the size you want?

Captivate 5, which ships with Adobe Media Encoder (AME), has the ability to quickly encode raw video as it is added to your project. This is only available by selecting Insert > Slide Video > (select raw video). The raw video is then compressed to your choice of FLV or F4V, then imported directly to your slide or project library.

The catch is that you have the option to choose whether to encode to FLV or F4V, but that’s where the customization train stops. You cannot resize the video or choose a different compression profile. Your only option once the encoding process has started is to duplicate the compression job, change the compression settings, and then start your queue again, but this severs the dynamic link to your Captivate project that made the whole process worthwhile in the first place.

If your raw video has already been compressed to the size you want, definitely consider using this capability because of how fast and easy it is. However, if you need to resize your video or compress to a specific profile, consider compressing with AME outside of Captivate and then importing the finished files after.

Do you want a video to span multiple slides?

Previous versions of Captivate restricted developers to one slide per video. To put it plainly, a single video could not span multiple slides. This is no longer a problem using “slide video”. When you insert a slide video, a dialogue box asks whether you would like to match the slide’s duration with the video duration or to retain the current slide duration and distribute the video file over several slides. If you choose to match the video and slide length, the slide length is increased, if necessary, to accommodate the length of the video. It is placed on your slide and automatically synchronized with other objects on the slide. If you choose to span multiple slides, the video is added to the selected slide and as many subsequent slides as necessary to complete the video. (Note: If the length and number of your subsequent slides is not enough to accommodate the video, the length of your last slide will be stretched until the video is complete.)

As with the video capabilities of older versions of Captivate, the Insert FLV option does not give you the ability to span multiple slides, but there are still a few things that this option provides that Slide Video cannot…

Do you want to add multiple videos per slide?

Attempting to add more than one Slide Video per slide will result in replacing the existing video with a new one. It is simply not possible to have more than one slide video per slide. Period. The ability to place multiple videos per slide belongs to Insert FLV alone. You can place as many videos via “Insert > FLV or F4V” as your slide requires and play them back to back, at the student’s discretion, or as part of slidelets, etc; the world is your video-inserting oyster.

Do you want your video to play in the Table of Contents?

Both methods of adding video to a project, by default, place video on the slide. However, new to Captivate 5 is the ability to play a video within the Table of Contents (TOC).

The TOC generally contains information like slide name and duration, progress, and course length, but when a slide video is moved from the slide to the TOC via the Video Management interface (Video > Video Management…), this information shifts down to accommodate the video, and back to its original position when no TOC video is slated. As with any other Slide Video, you have the ability to span one or many slides with TOC videos.

Do you want your video to be synchronized to the slide?

The ability to synchronize your video to its slide is a very powerful feature in Captivate. Translation: as the slide plays, the video plays, when the slide is paused, the video pauses, etc.) Previous versions of Captivate offered this feature as well, but it was not a graceful procedure. The video would often freeze and skip to keep time with the slide, and skipping forward or backward would often cause the entire course to malfunction.

Both insertion techniques offer slide synchronization, although in very different ways: Slide Video forces synchronization whereas Insert Video synchronization is optional. In my initial testing since the release of Captivate 5, the synchronization capabilities of Slide Video is much more seamless and I prefer to use Slide Video where possible. However, since both techniques support synchronization, the decision to use one or the other may depend on other important factors…

Do you want your video to have a skin (playback options)?

Player skins are only helpful if you do not plan on synchronizing your video to your slide and want to give the user control over if, and when, the video plays. Insert FLV is the only option available to you if you want or need playback controls on the video.

If you’re like me, you prefer the look of having no video skin, especially since the skins available within Captivate leave much to be desired. Unfortunately, there is a problem if you select Insert FLV: this method defaults the video volume to 50%, and the only way to increase the volume is through the playback controls. Slide Video defaults to full volume, since it is synchronized to the slide and does not offer playback controls.

Will you stream your video from a server?

Streaming video is becoming more and more popular as people expect to see video in a variety of computer interactions, be it from gathering their news for the day, entertainment, and now their computer-based learning. Captivate supports this feature, luckily, with both methods of inserting video.

Oddly enough, managing the video after they’re inserted entirely depends on how it was inserted. For example, if you add a local video (originated on your computer) via the Insert > FLV method, in order to switch from Progressive Download to one of the two streaming options, you must use the Properties panel. In the instance of a Slide Video, this information is managed in the Video Management dialogue box (Video > Video Management…)

Summary

Below you’ll find a summary of the video capabilities of both the Slide Video and the traditional FLV as discussed in this post. Hopefully you’ll find this information valuable as you continue developing with the newest version of Captivate. Best of luck to you, and feel free to share your comments and concerns with us regarding CP5’s video capabilities.

Recently, I delivered a presentation to Pensacola ASTD on Open Source Learning Management Systems (LMS).  During Q&A, I was asked why Open Source LMS is not more widely accepted in corporate America.  A simple question, without an easy answer.

Why does “free” Open Source LMS software lose out to commercial systems that require upfront capital $$ plus ongoing maintenance and support?  Is it because commercial LMS software is so much better and receives high scores for usability and customer satisfaction? Nope. In my experience, most companies struggle to gain user acceptance of their LMS strategy and meet their Return on Investment (ROI) goals.

Is it passed over because the feature set of commercial systems outshine Open Source? Hardly.  Both Open Source and commercial systems generally have far more features than most organizations need, and their users can digest.

So what keeps Open Source LMS relegated primarily to the University campus when the Fortune 50 consistently choose from a handful of commercial vendors?

My hypothesis is that Open Source loses because it is never seriously considered by selection committees.  Why is the “no-cost” option left off the table?  Because there is no “advocate” for no-cost options.  Ironically, Open Source LMS is disadvantaged specifically because it is free.

Selection committees, and the process they follow is designed to engage with, and solicit information from vendors.  They push the burden of information collection and exploration to the vendor.  Open Source software does not fit this established paradigm.

To understand why, let’s review a typical selection process.

1. Process begins with a business need articulated by an executive sponsor
2. Needs are translated into Functional and Technical Requirements
3. Selection team is assembled and a Request for Information (RFI) is issued to relevant vendors
4. RFI is followed by a Request for Proposal, (RFP) that leads to vendor presentations, deliberations, demos, dinners and maybe some departmental haggling on budget
5. Vendor is selected, and big bucks are remitted.

At each stage of the process, there is an advocate that motivates and drives progress.  Internal advocates are the project sponsor and stakeholders that comprise the selection committee.  External advocates are software salespeople and their respective company executives.  There is often interplay between advocates and various camps emerge that approximate reality TV.  Usually one vendor has the “inside track” based on a personal relationship among executives or committee members.  It’s a corporate drama filled with intrigue.

How does Open Source fit into the process?  It stands on the sidelines with no sales manager, no executive, no learning conference “guru”, and most importantly  no sales staff to respond to an RFP.  Open Source LMS may have a rich feature set, standards based architecture, and low price tag, but it lacks an advocate.  Without this role, there is no one to engage with the selection process and provide information and reassurance to decision makers.

Free software simply does not generate the incentive structure that makes the wheels of the corporate selection process go-round.  In addition, there is always a perception that free equals inferior.

So, how do you ensure Open Source gets the consideration it deserves in your selection process?  To leverage the benefits of Open Source, you must establish an internal advocate.  Selection committees must be flexible to keep Open Source on the table even though there is no company entity to respond to an RFP.  This may require designating a member of the team to compile and represent relevant information on Open Source options to compare against commercial products.

I am not suggesting that Open Source is a solution for every organization, or a majority of organizations.  However, even when you believe your organization will ultimately choose a commercial vendor, keeping Open Source on the table is a powerful tool for negotiation and accountability.

Educate yourself and your committee on Open Source tools and use this knowledge to challenge license fees and support costs. A wealth of information on Open Source is a few clicks away.  There is an established community of experts that can be accessed through online forums.  You may be surprised to find that information is more readily available on Open Source LMS than comparable commercial options with dedicated sales representatives.

Increasingly, basic LMS capabilities are a commodity.  Ask vendors to demonstrate why and how they add additional value that justifies the extra cost.  If nothing else, you will ensure the committee has fulfilled its responsibility for due diligence.  If you fail to consider Open Source, your vendor sales representative will thank you, but a tremendous opportunity for your organization will be lost.

Are you using Open Source LMS?  How did you arrive at your decision? Did Open Source factor into your LMS selection process?

Many in the eLearning space are still wrapping their heads around the iPad and what it, and the Apple/Adobe war mean for the future of eLearning.  One thing seems clear: the one-way road to cross-platform eLearning development, paved by the Flash Player, just added a few roadblocks.

iPad now joins the iPhone in a mobile device embargo of the Adobe Flash Player.  More importantly, Apple has made it clear that it will not accept iPhone and iPad applications created in Flash CS5 or any other development platform besides the approved Apple Software Development Kit (SDK).

So as an eLearning developer, you might be thinking, “what do I care… my Learners use PCs and Apple’s assault on the Flash Player is far removed from my world.”  From my perspective, the Apple/Adobe war is important to eLearning and mLearning (Mobile Learning) development for two reasons:

First, iPad reinvigorates the migration of learning from desktop computers to mobile devices.  While mobile learning has been a great talking point for several years, it was difficult to envision many practical applications of eLearning running on a 2 or 3 inch screen.  With the introduction of the iPad, even a modest visionary like myself can begin to see more clearly the shape of things to come.  The opportunity presented by the iPad is not so much about the size of the screen, but more about the convergence of screen quality, convenient size, battery life and most importantly, a sophisticated “touch” interface.

The introduction of the iPad increases the likelihood that Corp. Executives will spend more brain-cycles on mLearning opportunities versus eLearning.  eLearning may now be relegated to an organization’s portfolio of “traditional” Learning modalities which tend to attract less attention and investment.

Second, developers that hope to take advantage of mobile learning will live in a world less dominated by Flash and more driven by development technologies including JavaScript, CSS, HTML5 and Objective C.

In the late nineties, I led a team that pioneered the use of Flash and ActionScript in eLearning development.  I still remember the incredible push back from my team when I announced that Flash would replace ToolBook as our primary authoring tool.  I find it amusing now that one can barely imagine an eLearning application that does not run on the Flash Player.

In the decade that followed my decision to move our development to Flash, I watched as nearly every eLearning authoring tool adopted Flash as the standard for web published content.  I have also seen the complexity of developing interactive learning applications greatly reduced as authoring tool creators have successfully focused on ease of use to appeal to non-technical training developers.

I welcome authoring tools that simplify the process of creating  engaging eLearning.  I prefer to spend our time on designing and producing instructional media that drives training objectives.  However, its hard to deny the importance of the iPad and similar devices that provide a practical path to mLearning and blur the lines between eLearning and multimedia books.  To take advantage of these devices, developers will need new skills and capabilities or must wait for authoring software to retool in support of more “Open” standards that work with the iPad.  This, I fear, will be a long wait.

An obvious question for readers of this blog will be: “how about competitor devices that will surely swamp the iPad with support for Flash and additional features that approach the functions of a laptop or Netbook?”  My take is competitors will emerge and they will most likely be built on the Android platform.   As Hewlett-Packard recently conceded, competing with the iPad with a repurposed Netbook (otherwise known as iSlate) may not be a successful strategy.

What do you think? Is the iPad important to the world of eLearning development?

Have we all become too dependent on Flash?

Are we ready to take on the Apple SDK to create next generation mLearning or do we stick with our big happy “Publish” button that triggers programming magic?

Learn more about Flash in our Flash class!

Graphics and animations for eLearning and training content often build on each other as new graphic concepts are layered onto foundational concepts.  This layering of ideas can result in multiple composite graphic files that share common underlying graphical elements.  As the number of graphics in a project increases, the challenge of managing these files becomes increasingly complex.  This is particularly true when changes in an underlying graphic cascade to all graphics that share the common underlying element.
At SkillQ, many of our graphics and animations are designed in Flash CS4. To keep track of the files and assets used in a project and simplify the change process, we frequently use “shared libraries”.  Among many other uses, shared libraries are a means of accessing and managing the graphics and action script used on a project. Instead of embedding graphic elements in multiple Flash project documents (FLAs) in which they are used, categories of graphics may be shared and dynamically linked with each project.

A shared library is external and can be linked to many projects.  This can be helpful when changes are required for graphics that have many instances.  For example, lets assume you need to update a logo graphic that is an element of several animations used in multiple lessons.  If the graphic is contained in a shared library, it can be updated in one location and all Flash projects that reference that file will also be changed.

Shared libraries that are used by other Flash documents should be kept in a folder apart from the other Flash documents, preferably higher up in the directory structure hierarchy. Only the graphic elements that are unique to a specific document will be kept in that document’s internal library.

The benefit of using an External Flash Library is that you can store and categorize your graphics in one place and use them in as many projects as you need. Additionally, changes to underlying graphics are immediately reflected in all the Flash projects that contain instances of a graphic. You only have to re-publish the flash document that reference the library.

For more information on this topic sign up for an upcoming Adobe Flash Basics class.