Can anyone explain when you would select the "Force Re-Publish All The Slides" option within Publish ?
I have a feeling it has something to do with a project that you have made changes to after you have already published it, and you have to tell Captivate to update the changes before you publish the project again - but having to select this as an option that does not make much sense.
Maybe I have got it wrong.
Welcome to Adobe Forums.
You have created a project and publishe the output.
After some time, you did a change in a slide and you want Adobe Captivate 5.5 to publish all the slide (although you made changes only on 1 slide), then you will choose "Force Re-Publish All the Slides".
Personally, I'd like to see a bit better of an explanation.
Vikram says you created a project and published the output. Okay, all is well and good.
But here is the conundrum. At least for me. I always thought the action of publishing was re-compiling the output to create a completely new version of the output. Using a food analogy, perhaps the first action of publishing was similar to mixing ingredients into a mixing bows, pouring the batter into a pan and baking a cake.
When the statement is made that you are able to force all slides to be re-published, it's confusing. Again, with the food analogy, it seems to imply that you have a cake and you wanted sprinkles added into the mix. So instead of again mixing the ingredients to include the sprinkles, somehow you are able to leave the already baked cake in place and only somehow insert sprinkles?
I've long wondered about this option but have never asked about it. Happy to see someone shedding light on it.
Is this a time saving thing or what?
Perhaps it would be helpful to explain the process Captivate follows when publishing a project. I would think each time would involve simply copying the slides as they are into the output and compiling. But what was stated seems to contradict that. Is there a time where one would just click Publish and NOT see the updated content reflected in the output? And that would be why we need to somehow enable this setting and do the Publish hokey pokey again?
Helpful and Handy Links
The answers above confirm that I was right when I thought I was confused about the "Force Re-Publish" option, and I am still not clear.
Perhaps Vikram could answer my question based on the following scenario in regards "Force Re-Publish (FR-P)?"
I create a project.
I publish it (without ticking FR-P).
Later I make some changes to the same project and need to re-publish the project.
Question: Do I have to (mandatory) tick FR-P to ensure my changes are saved and will be applied to my newly published project ?
That makes no sense to me if that is correct. Any changes made - be it to one slide or across many slides - should be saved and become party of the new version, re-published project without the need to select FR-P.
As Rick says and as with any other situation (.doc or .ppt etc), if you make any changes to the original you are creating a new version.
To-date I have not never used the FR-P option and have re-published many projects and have not noticed any problems, so hope we can get to the bottom of what FR-P in fact does...and in plain (non technical) langiage please.
As per my understanding for Force Re-publish :
You created a project in Captivate 5.5 and you publish the Flash output (.swf)
You will get 3 files : .swf, .htm & .js, now you did changes on multiple slide of you project and you want to eliminate any possibility for changes not occuring on any of slides in output, You will check Force Re-publish
Generally when you publish your same project again in Captivate 5.5, it publishes changes only on those slides on which you made changes
Force Republish creates a new version of all the Slides in the published output.
Any comments are welcome, might be I will learn something new.
Thanks for your answers - and if what you say is correct - I have to ask the following.
Why then is "Force Re-publish" an option ?
Surely if you make changes to a project and regardless of how you publish it, surely Captivate should update all the relevant files automatically and It should not be up to the user to have to remember to "force" Captivate to do its job.
I have never used the Force Re-Publish option and have made many changes to already published .swf projects and as far as I know, the changes were saved and seen in the new version.
I am using v5.5. Is the Force Re-Publish also an option in v6 ?
I seem to recall Adobe hyped this as a feature during one of the Captivate version launches. The idea being that during the publish process.. only those items that you changed in a project edit where republished. This was designed to speed up the publish process which used to be very slow. It does seem to work and I think this is the default for Captivate 5, 5.5, 6. I use it often when I've made changes that affect several slides and I always use it after I've done my final edit on the project.
Maybe it is just me...but based on what you say, I just cannt get my head around the fact that you have to tick a check box to tell Captivate that you would like the changes you just made to your project saved!
Why would you not want to save all the work you have just done ?
It is almost as if there is a problem within Captivate whereby it sometimes forgets to save the changes and it is up to us to "force" Captivate to rememeber to do what it should do by default.
IMHO it seems that the Captivate development team needs to remember the following from this point thru forever: "Just because you can, doesn't mean you should!"
CP6 is loaded with way too many NON-features and the things that should work and work easily do not.
My wish would be that they stop using their imagination to come up with new "features" and start making the features that are included work properly with proper documentation. I personally do not think that is too much to ask.
But who am I to ask for such a thing.... oh wait, that's right, I'm a paying customer and as they say, "The customer is ALWAYS right!" ;-D
I totally agree with you and in particular with regards (1) Proper Documentation and (2) We are the customers - and high paying ones at that.
If it was not for the excellent support from a few dedicated people on this forum I would have given up long ago.
It's my understanding that the teams don't just sit around dreaming up features. I understand that the feature set is more driven by customer demand. One of the venues is the Wish Form/Bug Reporting Form. Each time someone submits something via that form, it's like casting a vote for the feature or bug. And the more votes cast for any given feature or bug, the higher the ranking behind the scenes.
I too disagree with certain features. For example, I hate themes with a purple passion. But I also temper that with knowing that the features likely weren't some knee jerk hare brained idea. There is a lot of thought, planning and careful consideration behind any change. Others obviously asked for it and I do actually see folks praising the feature.
And we have to face it. Captivate is, after all, software. And all software has bugs. And when new features are introduced, they likely may be misunderstood or improperly used. (when I say improperly used, I simply mean that we users don't use the feature like the developers intended for the feature to be used. Sometimes that's bad and sometimes it's good!)
So your statement bears true. The customer is always right. And even though you may not feel that's the case here, perhaps by my sharing my own understandings it will help that come into a better light.
Helpful and Handy Links
I see your point.... so I think a great idea would be for the developers to explain in the documentation how a feature is to be used. ;-)
But certian "features" just don't work and they have been in previous versions not working.
See the thread on Executables accessing swf files. I'm having the problem in CP6 and a friend with CP5/5.5 has the same problem. If we're not using it correctly then someone really needs to document how it is to be used.
What's killing me and others is the hours and hours we are wasting to try and figure out how things are supposed to work and/or why they are not working at all.
So now I'm off to the Wish/Bug forum to address the problems.
I also think it migt be easier of this forum was seperated by version - but that's a whole other can of worms
Please forgive the long rant...but I feel strongly about this one.
As a former Technical Author who worked for software companies, I agree with the sentiment that Captivate's software documentation could be more complete and more accurate. But, since my tiny little family company also now builds small bits of software (widgets) I'm also able to see Adobe's side of this current argument. We get lots of customers or potential customers that think we should build something THEY personally happen to want, regardless of the fact that it would cost us ten times as much to build it as they would be willing to pay for it. We pick our target features very carefully because otherwise we wouldn't make a dollar on widgets. (We can actually make 5 times as much money just spending the same time building courses for paying clients as what we can programming and selling widgets.)
So, like it or not, it's Adobe's development budget for CP and they really don't have to ask our permission to use it...even if we DO pay for their software...any more than Ford or Chrysler should ask my permission to build a new model with XYZ feature because I once bought a car from them. If Adobe ask my opinion about what I'd like to see in the next version, I readily give it to them. But that's a privilege they extend to me. It's not my right as a paying customer to demand they take my advice and build what I want them to. If I can make a good enough business case for a new feature I suggest, it might make it into the next version, but it might not because something or someone else has a better argument for where the money should go. Some of my suggestions ARE now in Captivate 6. A lot still aren't. I personally don't fret about that. I just get on with using the tool as best I can.
I even set up the Captivate6IdeaScale site just after Cp5.5 came out to give other users a more visible voice in what features they wanted to see. That site is still up. If you doubt that Adobe listens to its customers, go there and look at how many of the suggestions people posted are now in Captivate 6.
Honestly, no company wastes their development budget on things they KNOW will not work. But picking which features will sell a product and which ones won't is notoriously difficult. And whoever told you "The customer is always right" was lying to make a sale of some kind or has never studied some classic business successes and failures of the past. Predicting success is just NOT that easy, and customers are only experts about what THEY want, not what the overall market will respond to. Read some recent books about "Innovation" and you will see that we would not have many of the current products we enjoy if it were always just up to customers to predict what would work and what would not. Companies that can't get it right often enough go broke or get eaten by bigger fish. Customers that can't pick good products are what keep a lot of these hopeless companies in business longer than they should be. Take a good look at where Adobe is in the software world. They're not doing too bad. I certainly wish I owned the company.
At the moment a lot of what has gone into Captivate 6 has been about covering areas where Cp has been losing ground to other products. Themes, the new SCORM drivers, Avatars and Clip Art figures, improved video capture, are just a few examples. But I agree that Captivate 6 is having "teething problems" and I personally think it could have done with several more BETA versions before release. However, having been on the BETA program myself, I also think it's possible many of the issues we are now seeing would NOT have been revealed by several more BETA versions anyway because the BETA team simply cannot cover all of the use cases and platforms where bugs will show up. So getting the product out as quickly as possible (even though it was a dangerous gamble with stiff competition from Storyline now in the market) might in the long run have been the better move. Who am I to say? Which one of us has built or managed anything as big as Adobe, or even a product with as many users as Captivate so that we can sit in judgement of it? I personally just DON'T think my business skills are THAT good.
I'm not defending Cp bugs...I can give you a long list of the ones I would like to see fixed too. But anyone that has worked with Cp as long as I have is accustomed to seeing these sort of frustrated forum posts after every new version. Does this mean that Captivate is a shoddy product? I don't believe so. I also happen to have Storyline in my toolbox (just in case one of my clients asks for it) and after buying it I also watched the Articulate forums daily for a while. There were plenty of bugs being logged there too, despite the fact that SL went through about a dozen BETA versions before release.
Great reply, but I am still none the wiser in regards to exactly what is "Force Re-Publish" and when should it be used ?
I get the impression that if you do not tick the option after you have made some changes to a project and before you publish it, there is a chance that Captivate may NOT save the changes you made...and so it is up to you to "force" Captivate to save the changes.
I just need to understand exactly what this option is for and is it something we should tick each time we make a change to a project ?
I wasn't replying about the Force Republish option. I was replying in general about comments to the effect that Adobe might be obliged to do whatever customers wanted.
As I understand it the Force Republish option just compiles everything in the project SWF whether or not it was modified since the last publish. When this option is NOT ticked, Captivate just compiles the areas of the SWF that were modified since last time. This option was introduced because users were beginning to see longer and longer compilation times for publishing as Captivate projects became progressively bigger and more complex.
Since Captivate 5x came out it now uses XML and a huge cache (in My Documents > Adobe Captivate Cached Projects) containing a separate folder for each CPTX project file you are working on. If you take a look inside one of these cache folders you'll see EVERYTHING in the project is laid out there. When you publish a project, the relevant cache of files that make up the project get compressed and compiled to create the output SWF. However, to speed up the publishing compilation time, Captivate can detect which areas were modified and only recompile those bits. That's how it works by default, but selecting Force Republish makes Captivate go the long way around and republish everything again, whether it had been changed or not.
Thanks for the explanation.
Two final questions on this issue, if you don't mind.
1. With the above in mind what should I tell the Captivate (v5.5) users in my company when they ask me if they should select the option "Force Re-Publish" when they have made some changes to an existing project ?
I get the impression the general answer is "No...dont select it"
2. When should the "Force Re-Publish" option be used ?
Here's a reason to use it - if you change a project title when you publish, the change doesn't 'stick' unless you use Force Republish All. That is a good illustration of the type of files that do NOT get updated if you publish without that option checked.
I like the concept of having an option to publish everything or just the changes, though - publishing used to take a long time!
I used the force re-p and it removed all the edits I had made. It erased, in the original file (as well as the published files) all my edits. I had to re do 4 hrs of editing.
I would like a clearer understanding of how this feature/bug, is suppose to actually work.Thanks