What exactly is the problem?

A typical Captivate project, such as the Encoder Demonstration you experienced in Chapter 1, Getting Started with Captivate, involves taking screenshots of an actual piece of software. At the end of the process, the project will typically be published in Flash or HTML5 and placed on a web page (or Learning Management System (LMS)). Most of the time, that web page displays many other page elements (for example, logos, headers, footers, navigation bars, and so on) in addition to incorporating your Captivate movie. This can lead to a very delicate situation as illustrated by the following image.

The preceding image shows the application you need to capture on the left. Let's pretend this application requires a minimal width of 1024 pixels to be displayed without horizontal scrollbars. On the right-hand side of the image is the wireframe of the web page you must put your finished movie on. The page has been designed to fit a 1024-pixel-wide screen and has to display lots of elements in addition to the Captivate movie. To cope with the design requirements of the web page, your project should not be wider than 800 pixels.

So, here is your problem: you have to find a way to fit 1024 pixels in 800 pixels!

Several approaches are available to address this problem. Each of these approaches has its pros and cons. Following is a brief review of each.

Resizing the project after the initial shooting

The first approach is a two-step process. The first step is to shoot the movie in 1024-pixel size, and the second step is to use the Rescale Project feature of Captivate to downsize the project to 800 pixels.

By shooting with a screen size of 1024 pixels, the application will be captured in its intended size, matching the student's experience of the application!

The main disadvantage of this approach is that it requires resizing the Captivate project. In Captivate, the resize operation is a one-way destructive operation. It always has a cost in terms of image quality. Surprisingly, the resize operation can result in a larger file size, even if the new resolution is smaller than the original one. Also, in case the new resolution is smaller, the screenshots will be smaller as well, and the information they contain might become very difficult to read.

The following are a few tips to keep in mind when resizing a project:

Downsizing the application during shooting

The second approach is to downsize the application to shoot during the capture in order to fit the requirements of the project. In this example, this means the application would be 800 pixels wide instead of 1024 pixels during the capture.

As far as Captivate is concerned, this is the easiest solution, as no destructive or complex resize operation is needed. But for the application that is being captured, this situation is quite uncomfortable.

Remember that the application you capture requires a minimal width of 1024 pixels, so by downsizing it to a width of 800 pixels, it does not have enough room to display all its components and generates horizontal scrollbars. These scrollbars and their associated scrolling actions (if any) will be captured and will appear in the resulting Captivate movie. Also, scrollbars sometimes hide important information from the screen, and therefore, from your students.

Using the panning feature of Captivate

In the movie industry, panning refers to moving the camera while filming. In Captivate, it means that you can move the recording area while capturing the slides.

This approach tries to cope with both the requirements of the application to shoot and the requirements of the movie to be produced.

The idea is to leave the application to its intended width of 1024 pixels, and at the same time, define a capture area that is 800 pixels in width. During the shooting, the smaller capture area can be moved over the bigger application as illustrated by the following image:

In the preceding illustration, the capture area is the red rectangle. In other words, Captivate only captures what is inside the red rectangle. As you can see, the capture area does not always cover the same part of the application during the shooting.

This approach is a good compromise, but it has two major disadvantages. First, moving the recording area while filming increases the file size of your final movie. But more importantly, using this approach, your learner never sees the application entirely, which could compromise the quality of the learning process.

Using the Scalable HTML Content feature

Captivate 6 introduced a new way to deal with the size problem. The Scalable HTML Content feature makes the published movie fluid, so it fits the screen it is viewed on (even as the screen is resized).

For example, say you shoot and publish your movie at a size of 1024 pixels, but the movie is viewed on a website where the maximal resolution can only be 800 pixels. In such a case, the Scalable HTML Content feature scales the movie down to 800 pixels so it fits in the available space.

The main advantage of this approach is that it makes your Captivate content ready for mobile transition. When viewed on a tablet or a smartphone, the content will be resized.

The major disadvantage though is that you lose control over how your content will be actually experienced. Only a small percentage of your students (those who have the exact same screen as yours) will see the course as you designed it. The other students will see the course either bigger (which means possibly pixelized) or smaller (which may mean too small to be comfortable).

This option will be covered in Chapter 8, Finishing Touches and Publishing.

Conclusion

None of these approaches is perfect, but you'll have to choose one anyway. The best approach depends on the project, your learners, and your personal taste. Here are some general guidelines to help you make the best choice:

Finally, never forget that you are teaching. Your students don't care about your sizing concerns; they just want to learn something. If the chosen approach compromises the quality of the learning process, then it is the wrong approach.