Question of the Week: Adobe RoboHelp Projects… How Big is Too Big?

Question:

My team and I are preparing to work on projects in RoboHelp 8 and are looking into how to best publish the files. We're very interested in FTPing because it would give us the flexibility to publish on our own without depending on IT for deploying the !SSL files to the intranet (I have used FTP before, and it worked very well). However, we will need to request some server space so we can FTP our projects to an IIS server, but we are not sure how much IIS space to request. So, my question is, in your experience, is there an "average" MB per published project? In my own experience, the average published project has about 300 files (around 3.5 MB), and doesn't contain many attachments or graphics.  I don't foresee our team having more than 10 RoboHelp projects to publish, and I think we would be safe in asking for 5 GB of space (10 at the most) for the published files.

Also, is there a recommended limit on the MB size for a RoboHelp project? At which size would they become "clunky," and what would the !SSL size be for a project that big??

Answer:

That's a tough question to answer emphatically. The output folder within your SSL will get bigger depending on two things: the number of topics and, more telling, the number of images, audio files and animations you add to those topics.

In any event, you can get an exact size of your output folder with a simple right-click on the folder within the SSL folder after you generate. When you Publish the folder to your server, the storage requirements will be the same as the size of the output folder. As for exact size requirements for the space on your server, a few gigabytes should suffice for now (unless your project contains thousand of topics). As for RoboHelp projects that are too big, I wouldn't worry about project size unless your project has more than two or three thousand topics.

Leave a Reply

Discover more from The Logical Blog

Subscribe now to keep reading and get access to the full archive.

Continue reading