This article is an excerpt from Chapter 12: “Collaboration” from Mastering InDesign CS3 for Print Design and Production by Pariah S. Burke (Sybex, 2007).
Design–graphic designers, production artists, compositors, and typesetters–and editorial–copywriters, journalists, editors, and authors–have, since time immemorial, often been pitted against one another by the secular and incompatible tools and technologies on which they each depend. Editorial passes its text to design for copyfitting and layout, taking the copy out of the sight and control of its creators. Editorial must then wait for proofs to be returned from design. Changes–and there are often changes–have to be passed incrementally to designers to effect; after the first handoff, editorial must rely completely on design to update and correct what is editorial’s own work. That could be frustrating for anyone. Equally frustrating is the other side of the process where design personnel frequently must interrupt work on current pages to go back and edit text on previously completed pages. Frustration could lead to resentment and to conflict between the two departments. At the heart of all of it is the software.
The sky is blue, water is wet, editorial uses Microsoft Word. This undisputable fact of life is not because Microsoft Word is perfectly suited for copywriting and editing. Far from it. It has numerous flaws and quirks that increase the difficulty of day-in, day-out writing and editing. It’s the only choice for editorial for one simple reason: nothing better has come along. Or, maybe that should read, “nothing better has been presented to editorial.” There is competition to Microsoft Word, but writers aren’t using it for one of three reasons: they don’t know what other options are out there; the other word processors don’t integrate better than, or even as well as, Word with other applications in the workflow; or their employers, who suffer under one or both of the first two reasons, don’t give editorial a choice.
When it comes to Word competitors like Corel WordPerfect, WordStar, OpenOffice.org Writer, the Mac-only Pages, and others, switching from Word offers no advantage to the design-editorial collaboration. None of these applications integrates into InDesign (or its competitors) any better or worse than Word. Not one of them addresses the potential frustrations and slowdowns in the design-editorial collaboration.
Solving the Design-Editorial Collaboration Problems
In Chapter 8, “Stories,” you were introduced to InDesign’s editorial companion, InCopy, and given an explanation of the basics for using it as a stand-alone word processor. I won’t rehash that introduction here. This section is about how the designer or production person handles the InDesign side of the InDesign-InCopy collaboration. It’s not about you writing and editing stories in InDesign this time. It’s about you enabling editorial staff to write and edit stories in your InDesign documents. Before we get into the mechanics of that, however, I want to briefly explain why your design and editorial collaboration workflow needs InCopy.
InCopy addresses the largest and most common problems on both sides of the design-editorial collaboration.
- Editorial’s Biggest Problem Editorial must hand off its work to design and loses control of the copy at that point. Editors will not have direct interaction with the copy again before it goes to press, and changes must be sent to design to effect. Seeing the results of those changes means waiting on design to make them and then return a new proof. If multiple editors are involved in a story, proofs make the rounds before going back to design, meaning even more time is spent waiting to see the results of the copy edits.
- Design’s Biggest Problem Once designers receive original Word document copy, they place it into the layout, advise editorial of any overset or underset text, and often generate a printed or PDF proof for editorial. After the proof has been sent, designers move on to other tasks. From that point forward and until the document goes to press, designers typically can expect to be yanked out of whatever else they’re doing to make changes to the copy as directed by editorial. Such changes are communicated through various mediums: new versions of the Word documents that must be placed and styled again; emailed editorial directives and fragments of new or updated copy; marked-up paper proofs that must be painstakingly re-created in the document; or over-the-shoulder edits made during a personal visit from the editor. If multiple editors are involved a story, the designer may receive redundant or conflicting change orders. Moreover, change requests from multiple well-meaning editors can create a constant stream of copy changes that prevent the designer from doing anything but editing one or a few stories for significant periods of time.
- The InCopy Solution InCopy stories maintain live links to the InDesign layout. Editors using InCopy do not hand off their copy; it never leaves their hands. Instead, the InDesign user places it into the INDD document as a linked asset, applies the initial styling (if it wasn’t done already within InCopy), and saves the InCopy story from within InDesign. Designers can work with the text as needed, but it actually lives in an InCopy document that may be modified by the editor at any time without waiting for proofs, without sending change orders to design. Through InCopy, editors no longer have to blindly imagine how changes will affect the layout of the story; they will see the changes live, as they write. In fact, they can write and edit directly in the layout page! For editors, InCopy is control–control over their copy, control they should never be made to give up–wrapped up in a purpose-built word processor that isn’t littered with buttons and menu commands for envelope printing, electronic forms creation, Web design, and dozens of other features that have no relevance to writing and editing.
- For designers, InCopy represents freedom. It frees them from having to be both designer and editor. By putting total control over the content of stories back into its rightful hands–the editors’–designers can focus entirely on designing. There will be no more complete replacement and restyling of text stories after the initial import, no more red-marked paper proofs, a dramatic reduction in email, and fewer instances of looking up to see editors’ faces reflected in your monitor.
Pariah, a wonderful explanation of the workflow. Thanks for reprinting that.
A couple things …
- Assignments are optional. InCopy users can open the layout and edit stories therein. It is not the .inca file that adds check-in/check-out, it is the consequence of linking an .incx file to a layout.
- New in CS3: you can rename story files in the Assignments panel (whether they’re part of an assignment or not) in either ID or IC by checking out the story and then doing a southern double-click (click once … pause.. click again) on the filename in the panel. This doesn’t rename the actual .incx file on the server (or break its link to it) but it does help users who need to see entries like “Headline” and “Caption” there. The renamed stories are maintained even after check-in and check-out by another users by virtue of a new .xml file that’s generated and saved to the project folder when someone renames a story.
- Editors working on standalone InCopy files (.incx) whether or not they’re linked to a layout, see formatted text in Layout view, which can be helpful. (I think you said it was a blank page.)
- If an editor opens a standalone InCopy file that’s linked to a layout (I agree this is not a good workflow but it can come in handy sometimes), it’s immediately checked out to them. No one else working on the layout or assignment containing that story can edit it until the editor closes the file.
AM