How do you organize your files that are shared between multiple end products?

Report · Apr 22, 2015

Hi everybody,

I've been learning FrameMaker for just under a year and I'm tasked with being the resident expert. So far using FM has been strictly a research endeavor but now we are looking to use it for all of our standardized plans (approximately 250 business units in 60+ locations with any number of plans and associated documentation). The plans have to be living documents that will be reviewed and updated annually (in an ideal world).

I was hoping to hear what others have done for organizing working documents at this scale. At the end of the day there will be shared sections but I will be producing 250+ PDFs and RoboHelp menus to house all of these plans. My plan was to put them all into a single book file (I could do multiple books but then if I add any shared chapters I would have to open up all of the books to include it). I have written an ExtendScript code that will cycle through and include/exclude based on top-level element attributes. That way I have everything I need in one place and can push a button to make all of my end products while I am presumably sipping a delicious beverage and feeling like a genius. My major worry is that all of these plans will mean that my book may contain thousands of FM files and insets to Word and Excel, all of which have to live in a library that anybody can come in and find what they are looking for to make updates.

Have others had a similar situation? Are there any good resources for organizing and naming working files when they will be used for several products in FM? And does the fact that I will put all this in SharePoint mean I am headed for disaster?

I would appreciate any recommendations you might have,

---Corey---

Report · Apr 22, 2015

Corey,

Why would you have to open up all of the books if there are only some files in common between them? You only need to update the specific book before generating your output to ensure that the common files follow the numbering and pagination order required for that individual book.

The only time you need to have multiple books (i.e. the .book files only) open is when there are links between the books. Using multiple books would simplify things.

You might also consider including the common files as text insets (into a document) from a central library of common content files, as an alternative.

Also, if you put everything into a single book file and it becomes corrupt [that does happen - quite often when upgrading versions], rebuilding it will probably be a PITA.

If you're going to be having thousands of files that you need to maintain on a regular basis, then using a CMS (Content Managment System) would be quite high on my list of things to check out. Make certain that the CMS can read the internal FM metadata (File Info) and use it judiciously. Note: SharePoint is not a CMS [one client affectionately referred to it as SharePain, though this was several years ago].

Without additional details of what documents/files go into making up your plans & associated documentation and what sort of content is in the "shared" files, it's not really possible to make anything more than generalized suggestions. Examples would help.

Report · Apr 22, 2015

Note: SharePoint is not a CMS [one client affectionately referred to it as SharePain, though this was several years ago].

Wrestling with SP 2010 on a daily basis … CMS is just one of the potentially useful things it ain't. Luckily, it doesn't get anywhere near my FM source files :-}

Report · Apr 23, 2015

I Arnis,

To be more specific, these are emergency plans in the company. We're trying to standardize them across the company and fill any gaps we might have. Shared files may be anything company wide such as a general plan for high wind, bomb threat, earthquake, etc (literally any disaster, natural, accidental, or deliberate could have a dedicated plan and associated file/s). Then there will be files specific to each business group such as evacuation, shelter in place, chain of command and such.

So if we write a new company wide plan, every book will need it, so I would have to open every book and add it (not open every book at once, but one at a time). Whereas, if I were to put all the files in a single book, I just add it in one place. Since a large number of the plans we will develop with be shared, that would add up to a considerable amount of manual labor (which we are trying desperately to avoid).

The reason we are using SharePoint is that it is already used in the company for file sharing, and we can use it for file versioning (so if something does become corrupt we can, presumably, restore it).

I agree that a dedicated CMS would be ideal, but I don't foresee that happening without doing a funding request, testing, requests for information from vendors, contracting, negotiating, etc.

So to try to hit all of the points you brought up. The larger body of the files in the book will be shared FM files. We may have some legacy documents that will be brought in as insets (this way those who don't have an FM license or will not want to learn a totally new software package at this stage in their careers can make edits). My challenge is separating out the book files, the FM files, the insets and graphics, and then splitting them further by who owns them or who/what they apply to. So an earthquake plan that applies to everybody that includes an inset of text that will be used for another product, or a chain of command plan that applies only to 1 out of 250 business units.

---Corey---