With Macromedia Captivate, you can create interactive tutorials with recorded narration, built-in testing, with an easy, painless, and quick process. But now that authors can so easily create tutorials, they have time to think about the best way to deliver their content to end users, and to think about what works well with the Captivate workflow.
When I started using Macromedia Captivate early last year, I quickly learned that Captivate authors did not have a clear deployment path for Captivate content they wanted to make available on the web. This problem does not stem from Captivate - the tool has a plethora of publishing options. Captivate can publish to SWF file format, optionally wrapped in HTML, to Macromedia Breeze, a stand-alone executable with an auto-run option for CD-ROM delivery, e-mail, Microsoft Word, and you can even send your content to a server through FTP functionality from within Captivate. While heavily testing Captivate for my own use and collaborating with others in the Captivate community, I quickly found many Captivate authors that are experienced, organized, and extremely talented in delivering documentation, tutorials, and other various e-learning content.
To support effective and easy-to-use delivery of Captivate content on the web, I developed a utility, called CaptivatePlayer. In this article, you will learn how to deploy Captivate content with CaptivatePlayer.
Introduction
Captivate content is most effective when you create many small, concise Captivate demonstrations or simulations. This is because Captivate has to manage all of the media it creates: the screen-capture images, the audio narration, the custom text, cursor movements, and so forth. That is a lot of activity and assets to track. Even with a fast computer, it is best if you create many small Captivate demonstrations and simulations because this affects your end user. If the Captivate content is smaller, it is easier for an end user to follow and understand. Moreover, the actual SWF file size is smaller and results in quicker downloads, which ensures a better playback experience for the end user.
Following this best practice creates a challenge, however: You suddenly have a bunch of SWF files, and you might not be sure what to do with them. If you are like most authors, you probably want your users to access your Captivate content in a web browser on the Internet, your local intranet, or as a companion executable. Since Captivate creates an HTML file or an executable for each Captivate demonstration or simulation, does this mean you have to create a website just to manage all of your content? Do your users need to keep track the content (which, by the way, isn't the best experience for them)? What about the executables? Will the user see each piece of Captivate content as a separate "program"?
Using CaptivatePlayer
I recognized the need for Captivate authors to have a simple way to play multiple Captivate SWF files and to make it easy for them to set up since there are a wide range of skill sets and backgrounds in the Captivate community. In addition to making CaptivatePlayer easy to implement for authors, it needed to be easy to access and use for the audience. Creating a new HTML page that loaded the Captivate SWF files into the HTML files, per project was unappealing; equally unappealing was having multiple EXE files grouped together in a folder. Linking to SWF files directly in a web browser does not take into account various player version checks, control over how your SWF displays in the browser, or provide your user with any sense of continuity and navigation between each SWF file. You might be able to use the Captivate MenuBuilder for creating the necessary web content, but doing this for each project could be time consuming and redundant work. Captivate is fun and easy to use for end users; I wanted an easy way to quickly deploy created content to the web.
Figure 1 shows an example of a Flash tutorial I wrote that displays in the CaptivatePlayer (highlighted in green), through the Firefox browser. As you can see, CaptivatePlayer frames the Captivate content unobtrusively, and takes up very little room.
Figure 1. CaptivatePlayer highlighted in green
How CaptivatePlayer Works
With CaptivatePlayer, your users can view many Captivate SWF files through one consistent interface. CaptivatePlayer provides navigation for users to access all Captivate SWF files. Users access SWF files through a pop-up menu that contains all of the Captivate SWF file names.
Figure 2. Clicking Sections displays the list of Captivate content available to the user.
Figure 3. After users select a demonstration or simulation, a green checkmark appears beside the content title, indicating that users have completed viewing the content. By using a menu, you maximize valuable screen real estate. CaptivatePlayer also has controls for scaling Captivate content in case your users have smaller viewing areas. It also includes a mute option for audio.
Figure 4. Users can scale the window or mute audio
Figure 5. CaptivatePlayer contains a global volume control.
CaptivatePlayer does not include playback controls because Captivate already provides these for you when you create Captivate content. CaptivatePlayer displays in 100% of the browser window, again maximizing screen real-estate. CaptivatePlayer is one SWF file that dynamically loads the SWF or EXE files published from Captivate.
You can deploy Captivate content easily in CaptivatePlayer with the following steps:
Configuration Options
There are two levels of configuration that you can specify for CaptivatePlayer. The web and EXE versions of CaptivatePlayer read captivate_playlist.xml (a required file), to know which Captivate content to play. This is due to the way security is implemented in Macromedia Flash Player. A SWF file cannot read the contents of a local folder; you must manually specify it in the captivate_playlist.xml file. To do so, type the names of your Captivate SWF files into the XML file.
The XML file has a few configuration options that you can edit. These options control the way CaptivatePlayer plays your Captivate content. The configuration options specify:
Advanced authors can specify these options in the index.html file that calls the CaptivatePlayer.swf file, but the XML file takes precedence.
The following example is a typical web deployment.
Figure 6. For a typical web deployment, the folder would contain these files
Figure 7. For a typical executable deployment, the folder would contain these files
How to Use the Play List XML File
Before you get nervous, remember that XML files are just text files. You can edit them in Notepad, WordPad, Microsoft Word, or any other text editor. I prefer Macromedia Dreamweaver because it color codes my XML nodes, aiding readability. The following is the XML file in Dreamweaver:
<?xml version="1.0" encoding="iso-8859-1"? >
<captivate_playlist
autoplay="true"
"volume="50"
content="true">
<swf src="demonstration1.swf" name="Introduction">
<swf src="demonstration2.swf" name="How To Do">
<swf src="demonstration3.swf" name="Conclusion">
</captivate_playlist>
</xml>
When CaptivatePlayer uses the XML file excerpted in Figure 8, CaptivatePlayer performs the following actions:
Attributes for the captivate_playlist tag Value
autoplay true or false. Defaults to "true."
volume 0-100
scalecontent true or false. Defaults to "true."
In the code sample above, the SWF source tag has a specified name attribute. You could have used the SWF file name, but "Introduction" is more intuitive to the user than demonstration1.swf. If you want to add more Captivate SWF files, you simply add another SWF tag in the XML file, just like the examples provided. You can add as many SWF tags as you like, but you must have at least one SWF tag always present.
How to Use the index.html File
I included a default index.html file for authors with either a Flash or ColdFusion background. First, for those in a hurry, the HTML is already written for you; the CaptivatePlayer is embedded into the HTML with the necessary code to make it play in the full screen in the browser. Second, for those incorporating CaptivatePlayer into their own website design, you can copy and paste the code for embedding CaptivatePlayer.
For more details, refer to readme_index.txt, included in the ZIP file you downloaded in the Requirements section. It explains in detail how to customize and use the index.html file.
The CaptivatePlayer Source Files
There are many ways you can use CaptivatePlayer (as an embedded SWF file in HTML or as an EXE file) and it can be confusing understanding all the files included in the ZIP file that accompanies this article.
After unzipping the archive, the base level directory has two folders and three files (Figure 10).
Figure 8. The contents of the ZIP file, unzipped
For Flash Developers who need to use the CaptivatePlayer in an existing Rich Internet Application, the necessary files are in the "Flash MX 2004 Install" folder. Included is the MXP, which installs the CaptivatePlayer as a component in the Components Panel. I've included the MXI and SWC for Flash Developers who need those instead.
Figure 9. The three files in the Flash MX 2004 Install folder
For Flash Developers who have more specific needs to customize CaptivatePlayer, the "Source Files" folder contains the FLA file, created in Flash MX 2004 and source AS (ActionScript) files. This folder contains everything a Flash Developer needs to customize the design of the CaptivatePlayer, tweak the way it works, add functionality, and/or compile a customized version. A default setup file, used to initialize the CaptivatePlayer, is included in the includes folder.
Figure 10. The files in the Source Files folder
Back to top
Where to Go from Here
Macromedia Captivate is the easiest and most flexible way to create interactive demonstrations and software simulations. It is fun to use, does the hard work for you, and lets you spend more time focusing on polishing up your tutorial, simulation, demonstration, or test to make it more effective. Because I have prior experience creating these types of presentations manually in Flash, I know that Captivate significantly reduces the amount of time and work required to create these demonstrations and simulations. I hope that CaptivatePlayer complements your workflow by providing a final, easy step in deploying your finished work for your users online, on an intranet, or even running locally, off of another user's machine.
In talking to Captivate authors from all over the USA, from Canada to Germany, by phone and e-mail, I can definitely say there is room to grow and improve the way the CaptivatePlayer deploys Captivate movies. One author has requested that I add a global control bar instead of having Captivate generate one for each demonstration or simulation. This would help end users quickly access other Captivate content, not just locations inside one demonstration or simulation. Other authors, who have lot of Captivate content, called modules, also have sub-modules. They prefer the current menu to contain nested menus, like most context menus do today (File > New or Right click > Properties for example). This is especially ideal for users, because a volume of 50-100 Captivate demonstrations or simulations does not fit well into a one-level menu.
Creating these demonstrations or simulations is only part of the process. I created CaptivatePlayer to fulfill a need to deliver Captivate content quickly to users. There is still room for improvement as I have mentioned, so if the CaptivatePlayer does not satisfy your deployment needs, please do send me feedback.
Notes from the Author: