News

InDesign/InCopy CS1 Workflow Breakdown

04 01 2005
 
cs1
incopy
indesign
print
The InDesign/InCopy workflow that was introduced in the the first version of Adobe Creative Suite isn't the most intuitive system to wrap your head around. Once you do though, it makes a lot of sense and for some people out there, they may wonder how they produced without it.
    Basically, in CS 1, there a system called the "Bridge Workflow". This is not to be confused with the "Adobe Bridge" in CS 2 which is something much, much different. Bridge Workflow (BW) is a system wherein is separates out the software used for design with the software used for editing in to two products: InDesign (ID) and InCopy (IC). At first this separation may seem strange until you realize what it gives the designers and editors.
    For designers, it gives them the ability to truly lock down their designs. Design elements can't be moved as I've seen happen in a workflow that was based solely around Quark where an editor would nudge something a designer had done in order to make their copy fit. Yes, not a cool thing, but it happened and BW takes away that ability. It also makes it so that the copy in a layout is just another element along the lines of an image. I'll get back to that later as it seems to be the hardest thing for designers new to the process to understand.
    For editors, IC strips down ID in to a system that is most beneficial to editors. IC also lets editors import Microsoft Word files, apply style sheets to the copy and then hand that file off to the designer to link in to the larger ID document. Above and beyond all of these features, IC allows multiple editors to work on the same document at the same time. I've seen it be a huge savior when a crunch comes down the line.
    So, back to the idea of how everything fits together.
    Essentially, in this system, there are .indd (InDesign files) and .incd (InCopy files.) In addition to these, there are your standard TIFF, PSD, JPEG, EPS, PDF and a multitude of other file formats that are used in the construction of layouts. But here is the biggest trick in understanding how all of this works because if a designer thinks of an IC file as another file like an image file, then they'll understand how all of this works.
    IC files are separate files from ID files which link in to the ID file. They can be edited separately and those updates will show up in the final ID layout. It does get confusing for people because you can edit an IC file directly in IC or you can edit it through ID by checking it out to work on. The later is bound to be the preferred method of editing because it is the only way for an editor to see the copy fit in to the layout. If it is edited just in IC directly then they'll only see the text with applied style sheets.
    A strange thing for designers to get used to is that if they need to make changes to the text of an IC file, then they need to check it out just like an editor would. When you think about the whole workflow, it makes sense because in order for copy to be worked on, someone must check it out to work on it and thus it locks that piece of text, making sure that people won't step on each other's feet.
    It's through the check in and check out process that problems can arise sometimes. When a file is checked out, a lock file is created in the same directory as the IC story file. There are times (and this was much more prevalent prior to the release of the third software update) where a lock file would get written and then not get removed once the file was checked back in. This in effect locks the file to everyone, including the person who created it in the first place. The only way around this is to go on the server and delete the file manually. Also, making sure that users close out of documents and don't leave them open helps as well because any disturbance in a network will cause general weirdness.
    Another general suggestion is to make sure that designers are linking low res images in to their documents for production work. ID/IC has a bad way of opening a lot of connections to the server (one for every file that a document links to) and I've seen several instances where things move very slow when people are working on something like a 40 page document with a lot of images or are using full resolution images to mock up a layout.
    One last item to address before laying out a sample workflow is that one of the bad things about this system is the amount of files created. For every textframe in ID there has to be a corresponding IC story for it if editors are to be able to edit this. I've found that creating a good hierarchy for story files on the server will pay off big time. And lastly, I've never found a good way to save a draft in IC in order to come back to it later. You can only save versions in ID, but that won't touch to IC story files. Just something to keep in mind.