STS Blog

My current Shoap Technical Services assignment requires me to work with Captivate extensively. We use the tool to create walk-throughs of new systems and software, as well as web-based training packages that students can study independently, and at their own pace.

Normally, we’ll build the courses so that course navigation is part of the standard slide template that we use, like so:

This is handy since we like that students can skip back and forth through the slides, but the controls dissappear whenever a video simulation is shown… this way we keep students from skipping forward through the simulation and they have to at least pretend to watch it. This is great for course delivery, however if you are the person creating the slides and debugging the course, it can get very tedious and very boring, very quickly.

The solution is quite simple, even though it took me months to think of it.

Since Captivate allows you to “skin” your presentations with some pre-defined controls, I use the skin feature to my advantage.

Selecting Project > Skin… brings up the Skin Editor. I’m pretty sure you can guess what that does.

Clicking the checkbox next to Show playback control enables the skin – it will be shown over your presentation when you publish it. You can also use the Skin Editor to choose on which side of the presentation you would like the playback controls to be shown.

Now, when you render the presentation, it will have a nice control strip laid over the selected portion of the presentation.

I use this method when I publish presentations that I am going to review. Clicking and dragging the marker on the progress bar gives me an easy way to navigate through the simulations looking for spelling errors, issues with callouts fading in and out (or not doing it), timing problems, inappropriate mouse click sounds, and so on. And this way, it doesn’t take foreeeever.

Note: I used Captivate 2 for this article since it is what I currently have to work with. If you have a spare license for version 3 that they you don’t need for some reason, shoot me an e-mail ASAP! I’d love to take it off your hands…

Tell Someone About This Post:

I’ve covered in the past some of Flare’s wonky behavior when it comes it to white space. I found another fun trick involving white space while searching in Flare 2.5 yesterday.

One of the changes I needed to make on a document I was working on involved a global search and replace. I needed to change all instances of SnazzyGood API (names changed to protect the innocent) to Snazzy Good API Manual. Easy enough. However, I found when I was done that Flare’s search and replace had missed a number of instances. I took a look at the source of those instances to find out why.

It turns out that in the HTML, Flare occasionally inserted a line break and extra white space between SnazzyGood and API, instead of just a single space. Since HTML treats any length of white space as a single space, this:

<p>I like to use the SnazzyGood API</p>

has the same output as this:

<p>I like to use the SnazzyGood

              API</p>

But Flare treats them as different strings in searches, which is not the behavior I would expect. This means that you can’t trust any search with a space in it. Oh, Flare, why won’t you let me love you more?

Fortunately, Flare has the option to use regular expressions in searches, so we can work around this feature.

First, in the Find and Replace window, you need to tell Flare that your search will use regular expressions. Under options, select Use and then choose Regular Expressions from the drop-down.

Now, under Find what, you’ll need to replace any spaces with \s+. \s means any white space. + means one or more occurrence. So my search and replace becomes:

Not sure if the fine folks in San Diego have fixed this for version 3.0 or if they actually think this is a good idea, but in 2.5, you’ll need to use this any time you want to use Flare’s search and replace to find a string containing spaces.

Tell Someone About This Post: