Many newspapers seem to be making the switch to InDesign, and many are considering it.

QuarkXPress or InDesign? Both have their pros and cons.

This is not the place to provide an expert opinion on the matter, since I have been using InDesign for less than a year and with just one companion software, JazBox. But this could be a place to make some initial comments about the difference between our new software and our old newspaper software, a combination of Quark and DewarView. Others could add their opinions on their own software.

First, a caveat. I am sure that every newspaper who uses these systems have set it up somewhat differently, so that my experience may not translate to those experienced at other newspapers. So I encourage you to view this as an anecdotal story and that is all, perhaps revealing in the overall.

To understand how Quark and InDesign work at a newspaper, it is important to realize that this will be a lot different than Quark and InDesign function on their own. Some of the functionality I saw with InDesign at an Adobe class during a Society for News Design conference, such as the ease of bringing photos and graphics into Photoshop and Illustrator and having changes automatically update on the InDesign page, was more integrated than what InDesign CS can do as set up at my newspaper.

Companion software necessarily gets paired with the design software at newspapers. A database program that tracks all stories and pages usually accompanies the design software and the two are closely linked together. Pages for each day are usually separate documents from each other, so that one designer can be in one page and another designer in another. This becomes an issue with jumping stories to another page, since the text flows into a separate document, which inevitably causes challenges. Sometimes the editing gets done in a program such as Microsoft Word, and sometimes it gets done in a companion program to the design software, such as InCopy with InDesign.

Here is an example of how the ties between these programs worked in the Quark/DewarView environment. When DewarView was the database program paired with QuarkXPress, basic inside page layout (and even section-front design) was expected to be done in an area of DewarView called PageManager. Working in PageManager was like working with a combination of rectangles, some for body copy, some for headlines, some for photos, … You would see how the rectangles stacked together, but that was all. It was not necessary to even open the Quark page for the editors to get all of the headline specs for that page and to write all of their display type, such as headlines, captions, teasers, … In theory, story lengths were evident and the designer could just open the Quark page at the end of the process and it would be finished. In practice, it didn’t work this way at all, of course, and designers were constantly opening and closing the Quark page and fixing or modifying the basic design that was capable of being created in PageManager. At some point in the process, often at the end of the night, a lot of cleanup work was necessary on the Quark page. Story length indicators for editors also were not reliable. Many designers tried to abandon all ties to PageManager on section fronts and work exclusively in Quark. This involved copying and pasting the stories tied to the database into Quark so that no ties to the database remained. Headline specs and other display type were manually added to stories for editors to write. Editors who were not kept aware of how the design was getting placed on the page might expect they could sneak back into a story in the database to make changes late in the process, and in reality, it would never update on the page. Vice versa, late changes to stories and headlines on the page would not be saved with the version in the database. In short, having different designers using different methods to try to work around a too-basic page layout system was a bit of a nightmare.

Pros/Cons of Quark/DewarView

We used such an old version of DewarView that I really can not comment too much on it, since it will be unhelpfully out of date. Not many newspapers use DewarView. It was a basic program, and in our installation, seemed to be a source of instability in the system. But I do have a long history with using Quark. Because we were no longer updating our DewarView software, though, we were stuck with an older version of Quark than was widely in use. That said, Quark is easy to use, powerful enough, responsive and can be pushed on deadline to perform quickly and reliably. It’s ability to work with photos and type is basic, but generally good for newspaper work.

The pros of using Quark/DewarView:

• Our version of DewarView performed such simple tasks that doing anything in the system was like working on a single file, in other words, things happened at the speed you would expect them to happen. If you asked your story to save, it saved immediately and was done. Same with saving pages, opening drop down menus, copying files, … everything happens immediately.
• Since we treated jumps as if they were separate files, designers could design section fronts without worrying about jump-page design, resulting in stories being sent over to be edited much sooner than if the jump-page design needed to be completed first.
• Because photos were not visible on the page to editors, there was no need to wait for all photos to be on the page before sending the story along for editing.
• In short, the combination of the two programs resulted in basic and quick design.

The cons of using Quark/DewarView:

• Editors can not see the page, so they lose the sense of how it fits together or what other headlines currently are written for that page.
• You can not have two pages open in Quark at the same time. The PageManager program we used was not designed for this.
• Doglegging type over ads in our system threw off the trim specs on stories. The length indicator behaved as if the ad were not there at all.
• Pages in our system had a tendency to get corrupted and need rebuilding. On deadline this was very frustrating.
• Inevitably, the length specs even on layouts that did not pose challenges from ads were off. It was just difficult to set up the system so that these perfectly reflected reality. Final trims tended to get done by designers with an editor looking over their shoulder, or by editors on the page in Quark, even if the editor did not know how to use it, or by designers doing the trims themselves.

Quark to me is like an old friend. InDesign is a relatively new program that resembles Quark with a lot of familiar features added in if you are used to Photoshop and Illustrator. The companion database software paired with InDesign is even newer. JazBox is one example. DTI is another, and one I have not seen. At our company we seem to be getting software upgrades to JazBox every few months, as so much is being addressed, improved and fixed. It is nice to feel that we have real support available to us, and I expect as the programs gradually improve, this will be even more beneficial.

Pros/Cons of InDesign/JazBox

One of the realizations I made fairly early on with the InDesign/JazBox environment is that designers and editors have completely different experiences and views on the matter. While some designers feel it is a wash compared to the old system, and most feel it has some great features if they just fixed a few other odd behaviors, editors seem more frustrated by it than anything else. It slows them down and makes their jobs more difficult. At least that is the concensus opinion from what I’ve seen. This is an important consideration. It is hard to generate good buzz about a program when half the newsroom is frustrated and fed up. The main problems for editors seem to be speed and ease-of-use.

The pros of using InDesign/JazBox:

• You are doing all of your design on the real page, viewing real text at the correct size and font and with full control over almost all elements.
• The extra functions such as transparency, shadows and paths allow for more creative design right on the page.
• Editors can see the page in progress as they enter each story. They often mistakenly think they are in the page in InDesign, rather than seeing the last available view of the rest of the page (the view the last time the designer saved the page before the editor opened the story in InCopy).
• Editors can see how each line of type breaks, even in places where items and images are placed within the leg of type.
• While it takes awhile to set up a story correctly, it is very quick at the end of the night to update a story without the need to adjust boxes and clean up the page design. When I first switched over to using InDesign I felt as if I were so far behind in my design work. All night I was behind. It took such a long time to get each story ready to send along. But at the end of the night, without expecting it, suddenly I was done. Bamm! How did that happen?
• It is possible to set up the story with all of its related headlines, captions, photos and all length specs completely mapped out for late stories to be cut and pasted into the file later. This works really well with very late game stories from sports, as the editors can begin to write the display text early if they have a good feel for the story.
• When your program crashes (it happens), rarely is information lost. You do need to be careful about saving your stories and pages back into the database, though.
• It usually works best to set up the story completely, with both the section front and the jump page done at once, and all photos in place on the page. This is the ideal situation for the editors, as they can focus on the story all at once, see all of the art and how it is used on the page and not have to come back to finish stray elements or make trims later.
• There is a system for managing content to move online.
• It is powerful and smart. Sometimes when it comes to handling type and jump lines it is too smart, or considers itself smarter than you. Because more can be done to tag content, more will be asked of designers and editors to tag content. When you put more into it, you can get more out of it (or, more likely, somebody else can get more out of it).

The cons of using InDesign/JazBox

• It is slow. Saving the page takes so long that the designers have to plan strategically about when the best time to save a page is. Taking 10-20 seconds to save a page is not acceptable.
• It is complicated and particular. You must build, link and close stories and save pages in a very specific order for the stories to display correctly in InCopy for the editors. Adding elements to the stories such as headlines, captions, subheds and pullquotes is not as simple as dragging items out of a library and placing them on the page next to the appropriate story. These all must be linked into the story, which takes time. Then these items must be “dirtied” or modified in some way. The story must get closed (which takes time). The page must get saved (which takes a lot of time). If there is a jump page then it all has to be done in a very specific order for each page. At this point the editor can see it all and access it all in InCopy, once the story finally opens up for them in InCopy. Adding a cutline to a jump page could involve 10 separate steps and take four minutes, if you don’t go out of order and need to redo some of them.
• Doing tasks such as compiling a group of stories together into a briefs package takes far too many steps and too much time for editors who are used to something much simpler and faster.
• It needs help in the ease-of-use, user-interface department, such as when your long menu of paragraph styles constantly reverts to the top of the list as you enter new paragraphs, requiring long scrolls back down through the menu to the style you had just used.
• It doesn’t like text wrap or ads to interfere with jump lines. This throws off the automatic positioning of jump lines with the bottom of the last leg of type.
• Usually the same designer doing the section front will need to handle all of the jump pages, since both pages will need to be open at the same time every time you go into a story that jumps. There are a few workarounds here, but in practice it just works better to have control and constant access to all jump pages, and to keep them all open so that you don’t have to wait for them to reopen each time you put your cursor in a story.
• Since the desire is to set up the stories completely (including all art and jump-page design) before sending them on to the editors, this delays the time the editor has to work on the story. While it is possible to set up just the section front and do the rest later, in practice this complicates the workflow. I am aware of no designer working this way at my newspaper, even though we were accustomed to working this way previously.
• The program doesn’t like editors to open a story on the page when the page is getting saved (which takes 10-20 seconds, so it happens somewhat regularly). This prevents the layout view from working. The solution is as simple as closing the story and reopening it, but first a conversation usually takes place about why the layout view doesn’t work.
• You can NOT rush the system. The faster a designer tries to work, the more the program fails to register the keystrokes. When it’s busy implementing a task, it’s not paying attention to much of anything else you are asking it to do. Being slow and methodical is the fastest way to work.

So there you have it: one designer’s view of one implementation.