Meet Jack, the pagination guy

October 18, 2003

Jack Rosenzweig works for a company called Baseview, which builds pagination systems
for small newspapers. Jack started out as a copy editor in New Jersey, and did
that for a couple years before getting into pagination 11 years ago. At first he he
trained people to use his system, but lately he’s more of a honcho at Baseview.
I’ve met a few pagination vendor reps who were former desk people, so I figured
Jack could help us understand a bit about his job. The idea being that a little
education will make you less likely to belt your vendor rep across the nose when
your next major system install causes horrifying things to happen moments before
the press run begins. Jack lives with his wife and two kids near Ann Arbor Michigan.

Why do pagination systems drive us crazy?

Because that’s our goal, and we’re damn good at it.

I haven’t used them all, but from my experience the problem boils down mostly
to a couple things: poorly designed systems and a monumental resistance to
change from the newspaper staff.

Some pagination systems are so rigid they become difficult to assimilate
into a particular workflow, or so powerful and flexible they become a hindrance
when trying to them — the system in essence gets in the user’s way.

My philosophy, coming from the copy desk, has been to try to create the
tools that were a natural aid to the editor or reporter. Not to blow our own
horn, but the reporters can learn our system in an hour or less most of the
time. We try to make it as easy as possible. We frequently reject features
from the engineers — while they might be cool, they require too much innate
knowledge of the system.

And most journalists don’t want to be computer jockeys. I think that’s where
a lot of vendors get sidetracked: they forget that they aren’t selling software,
so much as a solution or toolset to a professional. The journalist should
not have to make a giant leap to this new tool.

That being said, some blame lies at the foot of the newspaper and its employees.
The newspaper makes what I consider a huge flaw when it hands pagination over
to the copy editors, most of whom these days have no clue about typography,
layout, etc. When I first used a pagination tool on an internship 15 years
ago it was like a godsend, because I was accustomed to doing my own paste-up
… Most journalists don’t have that background, so the page in Quark or CCI
isn’t an electronic paste-up board to them, it’s more like black magic. Some
of the more successful installations I have worked with converted the paste-up
staff into paginators.

Also, journalists, like everyone else, really abhor change. So they don’t
tend to look at a new computer system as something interesting or fun. It’s
amazing how much better an installation goes when the staff is into it, as
opposed to one where the publisher or corporate mandated the system.

And last of all … Software has bugs, always will. It’s a rule. Pagination
systems, operating systems, air traffic control, the space shuttle, etc. You
name it and it will have bugs.

Speaking of bugs: Why can’t you get the bugs out before the product is installed?

Why can’t you get all the typos and factual errors out of the paper before
it hits the press? 🙂

Same reason, human error, for the most part. Software is much more complex
that the average person realizes, there are probably millions of lines of
code involved. And there are so many permutations of how any one action or
interaction can be executed that its impossible to test every one.

These days there are also all of the external issues to contend with as
well — multiple operating systems (Win2k, WinXP, WinNT, Win98, Mac OS X,
Mac OS 9, Linux, etc.), pagination platforms (Quark, InDesign), and text editors
(Word, InCopy, CopyDesk), databases (Oracle, MS SQL, mySQL, etc.) you get
the picture. So not only do we have our own code to check for bugs, but frequently
we have to work around bugs in any of the above code that we depend on but
have no control over.

Believe me, we wish we could get all the bugs out. The programmers I work
with take a lot of pride in what they do, and are very upset when they learn
of issues that are causing discomfort with customers. But there just aren’t
enough hours in the day.

Time to market is a huge issue as well– one that is driven by the customers.
You all want the latest and greatest ASAP, and when we miss a deadline because
of bugs, we hear about it loud and clear. I can’t think of a single time that
I slipped a ship date and someone who wanted one of the upcoming features
said “no problem, we’d rather you take the time to do it right.”

Say I’m the nerdy guy on the desk and I want to follow your example and get
a job with my pagination vendor. What do I need to know before I make such a

Hmm … Danish?

I don’t really know what you would need to know to work for CCI. (CCI
is the Mercury News pagination system, it comes from Denmark — tm
) But
I think for the most part, the vendors are looking for people who want to
travel. In our case, trainers are out 50-60% of the year, usually only 2 weeks
at a time. Other vendors I know of have installations that take months and
the trainers rent apartments, etc.

Some vendors have a different training staff from the installation staff.
The installers are much more technical, while the trainers are more hands
on, patient types.

You have to have a lot of patience to be a trainer. You also have to be
a good listener. Understanding what the customer is looking for is a key to
a smooth installation.

And training is a broad term. I have trained people from how to use a mouse
to how to use our software to how to edit kerning tables in Quark to IP configurations
of the network. Some sites don’t have very knowledgeable support staffs, lots
of times the new systems manager was the person in ad composing who knew the
most about the computers. This isn’t an issue at the larger papers, but there
are lot more small papers than big ones.

I picture there having been a time in your career when you were slaving away
at your cubicle, racking your brain for ways to make your system kinder and
gentler to its users. Suddenly a lightbulb goes off that the system needs Feature
X. So you invest reams of time and energy into getting Feature X added, over
the resistance of bosses, co-workers and software engineers. After months of
fighting for Feature X, you get it added to the system — and the users yawn.
Has anything like this happened to you?

Not really…

(Ellipses are for a tale Jack told me so he wouldn’t have to give the
impression he didn’t have an answer; suffice to say my brain conjured a bit
more melodrama than his actual job does. Also, I wanted to have one ridiculously
long question with a two-word answer, in honor of George W. Bush’s news conferences.
— TM)

Word comes down from the glass offices: We’re getting a new editorial/pagination
system. What are a few things editors could do to take the pain out of the experience?

Learn something about layout if inexperienced. Learn how to use a computer
with a mouse if inexperienced. Learn the basics of the OS (Mac or Win) – file
system, how to print, how to get to a server, etc. Take a class on the layout
software – Quark, InDesign, etc. (if proprietary like CCI, you have to wait
for the class from the vendor)

If you have friends at another paper with the same system, go check it out,
get some pointers from them if you can.

The biggest thing is to make sure whomever is planning the installation
from the paper’s side gives adequate time for the training and practice. So
that new users have time to build pages and use the system before they go
live with it.

That’s really important, that you have pushed a lot of pages through before
being on deadline.


Comments are closed.