In Their Own Words: What Editors Have Learned About Working with IT
Stereotypically speaking, editors and software developers share certain characteristics. Both tend towards extreme interest
in their specialty area. Editors can be overheard chatting on the etymology of interesting words (e.g., "did you know that
the term edit is actually an example of back-formation? Edit is not the source of editor; editor is the source of edit."). And of course the Internet provides countless examples of developers who spend their free time crafting free code for
fun (e.g., http://dynamicdrive.com). Both groups could probably tell you the history of the term nerd or converse for hours about Star Trek. Both groups are driven to perfection.
But regardless of these complementary attributes, we often see conflict when the two groups work together. Many of you can
recall at least one meeting where eyes were rolling to the ceiling or heavy sighs were heard across the conference table.
This past month, we interviewed editors at various publishing companies to hear about their experiences working with information
technology (IT) staff.
Schedules
The processes, roles, and workflow for print production are well established, and most editors can give good projections on
pub dates once they receive a final manuscript. This isn't always the case for electronic products.
- One publisher we interviewed requires that all manuscript be in its final form and then electronic publication may commence.
Subsequently, the developers find themselves playing catch up to the editors because both products are required to hit the
market concurrently. After playing this game a few times, one editor simply pushed the pub date back to coincide with the
date the electronic production department could hit. "I recommend padding your timeline for a few publications. Go through
the process a few times and then you'll start to feel comfortable with two different timelines."
- Another editor shared frustration that an electronic project has been 6 months in the making and only in the 3rd month did
it become clear that all the meetings they had were for one facet of the entire project. Not only was this editor alarmed
by the miscommunication but also distraught with the time lapse. Continuously keeping track of the details while keeping the
big picture in sight will help to keep a software project on track but can seem a daunting task. Identify who should be kept
informed on the project's progress to ensure that someone is monitoring schedules.
- "It used to be that electronic product would appear 2 to 4 months after the print product appeared. Now it's 6 or 7 weeks
and our next phase is on-demand publishing to the web," stated one online journal publisher. Her best advice to navigate the
time issue is to "give it a chance. In the long run, work processes will become easier if you go in with no fear." And after
allowing some time to navigate the new paradigm, one editor explained that "now I finally know what questions to ask software
vendors."
Costs
- Good editors are able to anticipate costs based on what features their printed products will include. Good editors are still
unclear what costs are involved based on the features of their electronic products. "Costs are all over the place for some
projects. Depends on who you talk to. We had three very different quotes for the same project."
- Clearly it's true that costs associated with electronic product development have not leveled off to the same degree they have
with print products. One publisher addressed this issue by requesting product examples from developers. The editor decided
that the electronic product that fit her cost did not have all the bells and whistles initially desired but the core functionality
was there.
- It's often difficult for editors to grasp the costs of changes when they transition from the book environment to electronic
product environment. "Our book line changes run about 0.30 to 0.80 cents. That same change on one of our computer-based training
projects could be about a $60 change." How do they adjust? Editors we spoke to are learning that they can live with trivial
errors until the next version of the software.
- One publisher decided to approach the issue of varying costs by coming up with families of products. "One-off development
is just not feasible anymore. We are trying to put editors dreams in boxes that we know will work." This is a great approach
to developing electronic ancillary material for similar print products. Both editorial and EP know that both the requirements
and the end product will meet their needs.
Lingo
During our interviews, editors classified the most challenging aspects of electronic product development under the heading
"Miscommunication."
- The communication "Catch-22", as one editor describes it, is that while editors don't always know what functionality is possible,
developers are unable to give them clear guidelines on costs and timelines because they are looking to the editors to first
detail what they want. Both groups know they need to work with each other but clearly communicating is a problem.
- An editor in multimedia production said storyboards were extremely helpful to get over this barrier. They use simple Power
Point presentations to illustrate how the content will look on screen. As a group they now crank out 600 projects a year.
"For routine projects we have it down pat; for novel projects it's always a new approach."
- Everyone we interviewed stated that editors were involved from the beginning to help define requirements. One group even holds
"town meetings" where representatives from both editorial and development are present for an informal conversation about new
electronic products.
Final words
And what was the best advice we heard from all our interviews? Before you start work on an electronic product, "Have an actual
face-to-face conversation with your developer."
Privacy Policy |
Register |
Unsubscribe