Best practices for documents with boilerplate

[Nedlaw]

I apologize for the long post. This may be a how-to question as well as a best practices.

I have a project that includes several documents (more than the three in the illustration).

Three documents

 Each of the documents includes two different sets of boilerplate pages. They're boilerplate because they are identical. They go into each document at different places, but they are not simple block information. These boilerplate pages include images, several heads, and footers. Currently, especially the footers. By using boilerplate, I can maintain the pages in a single place so that they all read the same, but only until it's time to create the first Alpha draft. Then, I have to provide each book with its own copy of the boilerplate.

Because... The footers of each document include the product name. If they didn't, I'd just maintain the boilerplate in its own directory and insert the boilerplate doc using the book file where necessary. This is in fact what I do... but because of that changing footer, I have had to duplicate the boilerplate file for each book -- which multiplies the problem of maintaining all those "little changes" that crop up over time as the products mature and the docs go together. I use a text variable to maintain the name of the document... but even so, each book needs its own version of the boilerplate docs with the text variable set correctly in each component file of the book.

I'm looking for a way to maintain the boilerplate -- text&images or whole pages -- in one place and, when I cite them in the book file, they automatically adopt the correct product name for the book (presumably from the immediately preceding file) without me having to a) have a separate version for each product doc and b) adjust the content of a text variable.

Ideally -- I think -- this is the role of an INCLUDE command, where I could have a text-and-image object stored in a library somewhere and "insert it" into a regular page where I want the boilerplate to go (thus obviating the need to modify footers), but I don't believe ID offers that. And really, ID is WYSIWYG, so putting an INCLUDE in the middle of the text is probably not something that's going to happen. (However, I imagine it as something like linking to an external image. After all, the image appears, why not formatted text?)

Some kind of saved library object might work...

Have others run into this kind of issue? Is there an good way to resolve it? I'm coming up on another iteration of all these manuals, and I really would prefer not to try to maintain a version of the boilerplate for each product just so each product can have the product name in the footer (even if that product name is a text variable and I only have to change it in one place).

Thanks as always to the community.

-j

[Mike Witherell]

Have you explored the idea of making a boilerplate with multiple parent pages?

https://helpx.adobe.com/indesign/using/parent-pages.html

Did you know that many similar parent pages could be controlled by a super-parent parent page?

Have you experimented with Edit > Place and Link?

[Nedlaw]

Thanks for the excellent ideas!! No, I have not considered multiple parent pages -- but that makes a great deal of sense. Nor do I know anything about "super-parent parent pages." I will research that.

I'm less clear about using Edit > Place. Are you suggesting placing entire pages, text, or something else?

Thanks very much for your response.

-j

[Mike Witherell]

"Place and Link" creates a copy of something (like text) in document 2, 3, and 4. But you only edit it once, in document 1. It then updates in document 2, 3, and 4. 

[Nedlaw]

That's pretty much what I'm looking for!

Thanks again. Once I test these approaches, I'll mark them.

-j

[James Gifford—NitroPress]

Wouldn't this be a case for placed INDD pages?

[Nedlaw]

I think Mike Witherell made the same suggestion. Currently I create the boilerplate pages and then have to duplicate them -- one for each product -- because the footers must be custom to the product.

What I have yet to try is placing and linking a page... and then seeing if the TOC will include the heads on the linked INDD pages. Mebbe it will. Mebbe it won't.

Another alternative Mike suggested is creating a boilerplate doc with multiple parent pages -- one parent for each product, named appropriately. Then the boilerplate doc can go into any of the books, and it's only a matter of applying the correct parent page. I like that idea.

It's the pesky footer that's the issue. This is why I was asking about best practices in addition to how-to. I figured there might be a way where the cover page could include text (hidden or not) that the boilerplate could pick up. The 2nd boilerplate could then pick something up from the file that preceded it. That would work... but I can't think of a way to do it across files like that. For example, dictionary-style headers look for the first use on each page, but I don't believe they work across component files of a book. I could be wrong on that.

-j

[Mike Witherell]

BTW, how many similar documents are you producing?

And yes, InDesign allows you to place other InDesign documents into the InDesign document. When done this way, InDesign treats the placed InDesign document as an image file. You then have to Edit > Original to edit that placed page.

[Nedlaw]

There currently are seven product docs in the set (and the number is slowly growing). They average about 40pp each, so it's not like I'm updating War and Peace. The two boilerplate items represent 2 and 4 pages, repsectively. Still, that's 10% of the text.

Once I've distributed and adjusted per product the boilerplate, I have run into the problem where "a small rewrite" in one of the boilerplates (which should have been propagated to all the others) missed one. Sometimes it matters, sometimes no one but me notices. I would prefer not to have that issue.

The necessity of "de-normalizing" the boilerplates -- making 7 different copies and then trying to maintain them through Alpha and Beta drafts -- is what I want to avoid.

Can that "place-and-link" technique handle formatted text, head levels, and graphics? And then, what happens with those linked heads when I create a TOC?

-j

[Mike Witherell]

Heh! That is a VERY good question. Will it show up properly in a ToC gather? I don't know!

It should handle graphics and formatted text just fine.

[Nedlaw]

I can see that I'm going to have to experiment.

Thanks again. This is excellent info.

-j

[Joel Cherney]

The TOC only picks up paragraph styles in the live document, not in placed pages. (At least, that's the answer that pops up in my head. I didn't test it, but ten years ago I spent a lot of effort on pushing InDesign to handle long-document stuff that I would have previously done in Framemaker, so I'm pretty sure that I tested it at that time. But I don't remember actually running the test, and I bet you already know that you need to test it yourself instead of trusting Some Guy on the Internet.)

In your shoes, I'd go with Mike's other suggestion. Make a boilerplate "Original Boilerplate" parent page, then make new parent pages based on that Original Boilerplate page. If you're careful, then changes made on the "OB" parent propogate to the parent pages that iare based on the OB. You can also, in a new document, use the flyout menu of the Pages panel to Import your parent pages into new documents. I believe that you can do something similar with a Book file - I think it's "Synchronize Parent Page" - but I've certainly never tested it, and can't say that for certain. (Some Guy on the Internet Caveat applies here as well, of course.)

[Nedlaw]

Ah. Another Framemaker person. I was in the deep past.

-j

[James Gifford—NitroPress]

Raises hand. I only moved on from FM for "documents" and books because they went down that XML-platform road and quadrupled the price, or something like that. Glad that worked out so well. 😛

I'd love to see a next-gen tool that combines the best of both with more flexible/stable HTML/e-doc support... but hey, I'd like a pony and a date with [redacted], too.

[Nedlaw]

I don't believe Synchronize Parent actually works. However, I do know of ways to get Parent pages from one doc into another. I know that I can create a local book file that points to a boilerplate file located elsewhere. (Okay!) What I need to test is: when I set the Parent page of the boilerplate doc in the local book file (that points to a boilerplate page located elsewhere) does that change the parent page of the boilerplate pages in all the other documents that are ALSO pointing to the boilerplate page located elsewhere. I dunno yet, but it demands a test.

(Why is that important: Adobe packages)

Thanks.

-j

[Robert at ID-Tasker]

@Nedlaw

When you create a Book - you can set one document as a source for synchronisation - so you can synchronise Parent Pages, all Styles and Colors in all other documents. 

[Nedlaw]

Thanks to all that advised me on this topic. I've run some experiments, and this seems the best overall solution, although not perfect. There may be more elegant solutions that I haven't thought of.

• Create a boilerplate page using the same styles (para, char, etc.) as the rest of the book. Include styled heads and any graphics -- even linked graphics -- as needed.
• Select the boilerplate text-heads-and-graphics. (Note: not the page, not the text area, just the text/heads/graphics, the live contents of the page.)
• From that selection, create a CC Libraries entry (you may need to create a new library for the purpose or client). CC Libraries -- apparently -- enters your material as text, paragraph styles, and graphics, but they all appeared together when I entered them into a document. At least mine did.
• You can double-click the entry from the CC Libraries and edit it directly, then save it back to its CC Libraries entry. Thus, small changes at least are maintained in one place.
• In the individual document, on a normal run-of-publication page with whatever footer is needed, place the boilerplate (heads, graphics, and all). The heads will be recognized by the TOC production process. I'm presuming that any numbered captions will number correctly when numbers have been updated (more testing, I'm afraid, but I see no reason why this would not work).
• Run the book.

Downsides:

• While you can edit the CC Libraries entry directly, the entry does not automatically update in any placement you have already made. There is no active "link" -- all you have done is copied text/heads/graphics/styles from CC Libraries into the working document, much like doing a copy-and-paste from some standalone boilerplate document in your file system, except you don't have to copy it every time. <oh well> However, this does solve the problem of making ongoing changes in one place without "de-normalizing" the boilerplate into several independently maintained copies. The pesky footers -- each with a different product name -- are now the province of the parent pages of the separate books, not something that needs to be managed by the boilerplate page.
• This process could be enhanced IMHO if you were able to link the text to the CC Libraries entry, so that modification there modified the material where it is used, much as editing a graphic in PhotoShop and saving it to the same linked  filename updates within an ID document. (Maybe this feature is available and I just don't know about it. Ignorance can be cured, I'm told.)

Again, thanks to everyone who advised on this.

-j

[Nedlaw]

Small edit: select the text box, not the contents only.

[Robert at ID-Tasker]

@Nedlaw 

For the "text" contents - you can link to the TXT file or RTF/DOC file.

If you use DOC/RTF file - and keep EXACTLY the same names for the styles in WORD and InDesign - you'll save time on formatting it again in InDesign.

That was of my ideas how to automate things. That or link to cells in Excel or what you've mentioned earlier - variables. And then everything updated automatically.

[Robert at ID-Tasker]

@Nedlaw

You need a custom CMS. 

Do you work on Windows? 

[Nedlaw]

I do work on Windows. Whatcha got?

[Robert at ID-Tasker]

I do work on Windows. Whatcha got?

By Nedlaw

The best tool you can get 😉 

Isn't free - but I'm sure we can find some middle ground. 

It took me about 60 seconds to figure out at least two solutions how to automate it - but it will take me at least an hour to explain 😉 so maybe we should go private? 

In short: 

- you could stay with variables - my tool with update them automatically, 

or

- my tool can update / replace bigger pieces of text contents. 

Configuration: 

- you can either set things more or less "hardcoded", 

or

- you can have Excel sheet with more dynamic data. 

Either way - you will be able to focus on the contents - not how it should be updated. 

And you don't have to do many manual steps - one click and you'll have final PDF "ready to go". 

[Robert at ID-Tasker]

@Nedlaw

I've sent you message privately - please check envelope icon at the top of the page - this forum doesn't send notifications.

[Dave Creamer of IDEAS]

I would consider creating the boilerplate content in InCopy or InDesign (and export as InCopy). Use a simple InCopy workflow for the boilerplate documents--I would put on their own layer. An editor could simply update the files as needed and they will update in the InDesign documents. The editor need not have InDesign, but just InCopy ($5/month US).

[Nedlaw]

David Creamer's idea of using InCopy may be the solution I have been looking for. (Trust, but verify. I shall.) As a single-person freelance shop where I am the writer, editor, designer, and sole provider of revenues and feeder-of-cats, I have not bothered a great deal with the division of labor that InCopy provides (i.e., I am woefully ignorant of its use and benefits). However, InCopy comes with the CC suite, for which already I monthly donate the requisite arm and leg. After spending a profitable day with Adobe tutorials (it took me a short while to get past the woman with the Australian accent pronouncing "text box" as "tick bock") and various 3rd-party YouTube videos... I think this may be the way to handle evolving boilerplate for a document series, even for a one-horse outfit like me. As a techie, I lean towards the technical. Nah. I run towards it. This solution is certainly technical and offers a wonderfully appealing, if decidedly Rococco, approach. Watch for indicatory cherubs in my upcoming drafts.

Many thanks to the community for its continued support.

-j