Adobe Captivate 5 has a new publish engine which tries to detect the slides modified by the user and just republishes the slides changed. In this post we will try to take a deeper look at captivate’s incremental publish engine.
An Adobe Captivate project consists of a number of slides. In earlier versions of Adobe Captivate modifying any slide and publishing (Preview – F4 or Preview in Browser – F12 or Publish SWF) would result in the swf data for all the slides being generated irrespective of whether the slide was modified or not. This obviously is an expensive operation resulting in longer publish times even for small modifications. This often led to longer development times for an e-learning course or led to users often previewing after developing significant chunks of the course resulting in more rework if something was not as they had expected.
When we decided to rewrite Adobe Captivate, we took a re look at the publish workflow and tried to see where it could be improved to decrease the time captivate blocks users from getting on with creating content.We decided to see if we could take the idea of incremental building which has long been available to programmers and apply it to Adobe Captivate. The result of this exercise was the new incremental publish engine.
Simply put the incremental publish engine tries to publish only the slides that are modified. For slides that are not modified it tries to reuse the data that was generated for the previous publish. Normally the slides that are modified are the slides that are modified by the user. However because of Adobe Captivate’s reuse of resources across slides to reduce the output swf file size there are various dependencies between the slides.
Let us take a simple example. A sample Adobe Captivate project has 25 slides with some content. The initial publish publishes all the 25 slides. The user then adds a caption on slide 12. The incremental publish engine detects that only slide 12 has been modified and republishes only slide 12. The slide data from the previous publish is used for slides 1 to 11 and slides 13 to 25.
Lets have a more complex example. A sample Adobe Captivate project has 2 slides. Both of them have the same master slide.A logo image placed on the master slide so that it is reflected no both the slides. When this project was initially published the logo image from slide 1 is reused in slide 2 to reduce the file size. The user then unlinks slide 1 from the master slide.The incremental publish engine now has to not only detect that slide 1 is modified which is trivial but also that slide 2 is reusing an image on slide 1 which comes on slide1 because slide 1 is linked to the master slide. Since the linkage between the master slide and slide 1 is broken, slide2 should also be republished.
This linkage across slides can become quite complex and span across multiple slides.However the incremental publish engine is able to handle all these cases quite well. If at any time you find that the publish output does not match what is expected, a fail safe option is provided. This is available in the Publish dialog as “Force re-publish all the slides”. Selecting this option would force the incremental publish engine to publish all the slides irrespective of whether they are modified or not.
We collected some data on the performance of the incremental publish engine. We recorded a simulation consisting of 254 slides in Adobe Captivate 4 and measured the time for publishing after each set of changes and time saved. The same project was upgraded and published in Adobe Captivate 5
| Run Number | Slides Changed | Slides Affected | Compilation Time CP4 M:S:MS | Compilation Time CP5 M:S:MS | Fraction of Compilation Time | % Time Saved |
| 1 | 254 | 254 | 1:45:13 | 2:05:13 | 100% | 0% |
| 2 | 0 | 0 | 1:45:13 | 0:05:23 | 4.17% | 95.83% |
| 3 | 5 | 5 | 1:45:13 | 0:06:10 | 4.87% | 95.13% |
| 4 | 25 | 25 | 1:45:13 | 0:11:0 | 8.79% | 91.21% |
| 5 | 1 | 101 | 1:45:13 | 0:36:66 | 29.29% | 70.71% |
when i am publishing my project in captivate 5, it always stops in the final output….what should i do in this case
Jay, I appreciate how that might seem frustrating, but i think i should point out that Captivate is not a Word Processor. It would be more appropriate to compare it to a development environment, and many of those feature this sort of alternate method of quick save and deep save.
I think its important to optimize save times, and I understand that in any development environment it is possible for the user to make adjustments with code or advanced actions that could never be anticipated.
I think the case Dusty lists above is a valid bug and should be addressed, but unsubstantiated broad statements like those in your last couple of paragraphs make your post seem somewhat inflammatory & capricious. Perhaps you could state clearly any bugs or issues you have with Captivate 5, so that engineers might seek to correct any outstanding issues.
Of course it’s always important to maintain quality, i’m just not sure that you’ve hit upon an issue here that matches your description. Nor do I agree that insufficient resources are devoted to Captivate. Rebuilding an entire application including all features for both Mac and PC in a single release cycle and adding amazing new features is clearly an awesome accomplishment. While I recognize your right to voice your opinion, and I therefore approved your post, I have to say that I respectfully disagree with what you say here.
This is SO Adobe Captivate! Can you imagine Word offering you a “Save” dialogue with a little checkbox saying “Make sure it’s really saved”?
Why would you include a feature that cannot work consistently? Should I recheck the whole project every time I publish it (saving me seconds in publish time and costing me hours in testing time)? Or should I just feel lucky and hope for the best? I think I will just make sure this box is checked at all times… Oh wait, Captivate cannot even remember this setting, I have to check it EVERY time. Well done folks.
If you cannot make a feature work, do not include it in a final software. Adobe Captivate is famous for even basic features to be really broken (bullet points? scoring problems? font aliasing? the list is really long).
I am truly amazed that a company that released epic apps like Photoshop, Flash and many others, cannot devote enough proper resources to make Captivate worth the money and worthy of Adobe family name.
Useful feature, but I’ve found that CP5 does not always catch every slide that was updated when I publish. In other words, some slides that I’ve changed are not being published so when I upload the new SWF to my server to test the elearning, changes that I’ve made are included.
For example, I’ve recently made changes to some quiz settings on some slides, and some “Advanced Actions” settings and when I published the course, these changes were not published so I had to force CP5 to republish all slides in order to get these changes to be published.
In short, great idea to same some idea, but please adjust so that this works both quickly AND accurately.
Thanks,
-Dusty.
Dusty – that looks like a bug. Can you please log the specifics with wish-captivate (at) macromedia.com?
Incremental publishing is certainly a great step forward in Cp5. Well done guys!
You must be logged in to post a comment.
