End of the front-end: the case for the Recycling Center

Front-end systems were brought into this world to replace production systems, which had been the first forays into cold type composition.

Early production systems only captured writers' and ad-takers' keystrokes through OCR -- optical character recognition. So, the thinking went, if VDTs were attached to a production system and the software was made easier to use, perhaps the staff could be trained to use these beasts.

Thus, the primary task of a front-end system was composition. A secondary chore was to manage files; the third big job was to provide writers, editors and ad takers the capability to manipulate their words.

In the 1980s, newspapers had two discrete front-ends -- editorial and classified -- that were not connected in any way. They set type and that was about it. "Imaging" systems were in fact our traditional cameras and darkrooms. Business systems generally were linked to classified front-ends only by magnetic tape.

At the core of newspaper systems were these front-ends.

Let us not forget that front-end systems were designed before there were microcomputers -- before there were graphical user interfaces.

They were designed in the crucible of producing daily newspapers and they were refined quickly. They excelled at manipulation of text; even today, a good Atex or Coyote user probably can write and manipulate words faster than even the best user of an off-the-shelf word processor.

There were -- and are -- downsides to front-ends. They had their limitations, ones that seriously restrict their future roles.

I remember working on the AP/CompuServe project in the early '80s and fighting with my front-end supplier about sending out 2400-bps text to be uploaded on CompuServe. CIS wanted to support x-on/x-off flow control, but the engineers at the supplier company had never heard of such a thing. All they knew was wire service influx -- the data just keep coming down the mountain, they don't go up.

Most front-ends in place today pose data problems for their owners. They can handle only certain kinds of input and output, and they aren't very good at being able to tell you much about your database or working with anything except text.

In discussing the timely death of the front-end, I have to give you some of my working assumptions about the newspaper world of tomorrow. I'm convinced we will continue to provide the lowest-common-denominator information distribution system -- news on newsprint.

But I see a future for every newspaper, large and small, that will include an on-line version of the newsprint product, a fax-on-demand system, an audiotext system and maybe even a system for delivering the news over radio waves to personal digital assistants or through CD-ROM publishing.

One chart with this story gives my impression of a newspaper's revenue base today: 99 percent of it comes from newsprint-related activities. It's either advertising income or circulation income.

A second chart gives my projection for revenues in 2004 -- just 10 years away. You'll notice that newsprint is still a big piece of the pie; I'm figuring about 50 percent.

But look at all those other sources: a big chunk from on-line services, a smaller chunk from fax-on-demand, and succeedingly smaller chunks from audiotext, PDAs and CD-ROM publishing.

We've all heard a lot about Prodigy, America Online and CompuServe as on-line environments. Through one of them, it's relatively easy to get into the on-line world. You don't need to be the New York Times, Los Angeles Times or Gannett Newspapers to do it.

Any big on-line service provides you as a publisher with a critical mass of users -- readers. But since the most compelling part of your product is your local news, the critical mass of users you desire is in your own backyard. That's why new systems, doing new tasks, are likely a part of your newspaper's future.

For less than $5000 in hardware and software, you can build a good on-line system with graphical user interface support for Windows and Macs, and e-mail that can support up to five dial-in phone lines. For another $5000, you could provide connectivity to the Internet.

At this point you can decide if this on-line service will be advertiser-supported or reader-supported -- or, like your newsprint product, a bit of both.

This requires a certain amount of local marketing, but isn't that something you're supposed to be good at, too?

Fax-on-demand systems are relatively easy to develop on your own as well. The hardware and software is pricey (figure on $20,000) but again, you make the sole determination about your revenue mix -- and you don't have to share the profits with anyone.

While audiotext systems have been around for a few years, their use is gaining momentum because, again, for a relatively small capital investment, you can have the hardware (and total control) in-house. The major audiotext providers can give you consolidated service, but I believe this is another technology that should be brought under your roof.

A newer method of distributing news and information is just on the horizon: Personal Digital Assistants (PDAs).

Right now, the PDA revolution is concentrating on getting the little things to work right -- Apple spent the better part of a year trying to get the Newton MessagePad to handle handwriting recognition -- but the next step will be to embed a data radio receiver in this little box.

When that happens, a newspaper could distribute its information to readers at all times, updating stories as warranted. In fact, a basis for this technology has been developed by the pager industry, where news is broadcast to what are called "alpha-numeric" beepers.

Use of the CD-ROM is gaining momentum as well.

In appearance and price, a coffee-table book is pretty distant from the newspapers you publish. But when you buy Alice to Ocean (Addison-Wesley Publishing Co., $49.95), it comes complete with two CD-ROMs -- one an interactive exploration of the story told in the book and the other a Kodak PhotoCD, which allows the reader to look at the pictures from the book in any order.

Similarly, as an experiment the Los Angeles Times has created an interactive CD-ROM about the 1993 Super Bowl. The Times included not only the stories, pictures and graphics published in the paper, but also video images its staff photographers made at the game.

To achieve these goals of realizing a diversified revenue stream and addressing all facets of new media, we're going to have to reorganize our systems. Rather than looking at the editorial and classified front-end systems as discrete components, we're going to have to explore ways to link them easily.

We must have a huge database.

I've talked to a lot of database gurus, and they're skeptical that this huge database can be administered effectively. They're concerned that it will be slow to respond. So they seem to be drifting toward the notion of a database of databases, which Nora Paul of the Poynter Institute calls the Recycling Center.

In my opinion, a daily newspaper's Recycling Center will rely on 11 discrete systems to function. Let's take a look at what I think each will do and how they'll interconnect:

The first aspect that has to change is its ability to get to external databases. It must be able to allow a reporter access to campaign contribution databases, public record databases and our own in-house databases -- such as the marketing data we keep and our circulation database.

This new editorial text system should also allow for e-mail both inside and outside the organization. As more companies acquire Internet mail gateways, the easier it will be for reporters and editors to contact news sources via e-mail. And this mail should be piped straight to the reporter or editor's desk.

Workstations on our new editorial text system will need to run programs simultaneously -- multitasking. A reporter should be able to have e-mail, text editor and database query applications all open and running at the same time.

And let us not forget about SGML -- Standard Generalized Markup Language. Conceived by the world's largest publisher, IBM, SGML has been adopted pretty much throughout the defense-related industries.

I like to say that SGML is just like putting a typesetting format on a story: You put in uf123 or somesuch to get a headline; in SGML, you'd put in a tag that reads <headline>. Now, you might put ufsubhead to get a subhead; in SGML, you'd put in a tag that read <subhead>.

New editorial text systems will have to support SGML because eventually wire services will be transmitting their stories in SGML format (see The Cole Papers, August 1993). The NAA/IPTC committee putting together the next generation of wire service transmissions -- it's called the UTF, for universal text format -- has based its work on SGML.

But tomorrow's imaging system must be more than a picture desk -- it will have to handle photo assignments, capturing data about the pictures before they're even taken. This assigning information will be useful when attempting to determine which outtakes will be archived and which will be discarded.

Like today's picture desk, it'll have to handle wirephotos and probably both still and motion video -- as well as provide on-line access to high-resolution pictures stored in its archive.

Most of us wouldn't think of those two or three Macintoshes in the art department as a graphics subsystem, but they are. To realize their potential, we just have to add tracking and archiving features to them to give us the capability of knowing what was assigned, what came in from the wires, what we used and what we kept of those we didn't use.

The advertising text system must have communications and storage features the old classified front-end lacks. These would allow electronic input of national classified, permit an average reader to use the on-line system to input a car-for-sale ad, and provide space for a year's worth of liners on-line for historical and restart purposes. As with the editorial text system, this one also should support SGML.

The advertising display system must be equally adept at ad order entry and display ad makeup. The order-entry component needs to be connected to an electronic data interchange (EDI) network to get space reservations.

Further, the display system will have to support many formats, but most frequently PostScript (EPS and Acrobat, too), TIFF and such application-specific formats as MultiAd Creator and FreeHand. As always with these subsystems, it will need its own on-line archive for historical as well as restart reasons.

It will have to accept data from a variety of sources -- including the circulation system, so that it can tell editors just which products customers have ordered for that day so they can build those products.

The system will also have to begin to use "expert" or "smart" or "artificial intelligence" systems to learn how to build certain kinds of pages. (There are many pages in our papers that an expert, rules-based system could implement with little human intervention.)

When someone peeks into an on-line area or seeks certain fax information, the billing system must be able to register those usages and bill the customer accurately.

The circulation system would have many of its old traits but would also be a window into the local market. We'd know who subscribed to the paper -- and in what formats -- and who didn't.

It would be able to give editors data about building zones and specialized products, as well as driving the mailroom equipment to deliver those newsprint-based products.

These new systems will have to support new data types, including motion video, audio, fax, etc.

In the future, you'll have the Master Archive.

It will contain not only the text -- this time stored in SGML format rather than in the proprietary format of your library system supplier -- but it will also contain images (probably in Acrobat format) of whole pages.

It will know where you kept the high-resolution versions of your pictures (back there, on your image archive), your graphics (over there, on the graphics archive) and your display ads (up here, on the display ad archive).

Your master archive will be like your library system in that it will undoubtedly be administered by your librarians.

It's here that the people building the CD-ROM on your local election will go to retrieve material for that product.

It's here that your on-line system will put together a history of the high school football team's progress.

It's here that your PDA editor will plunge in to get a simple graphic to illustrate the breaking news of the latest software merger.

The Recycling Center will be a database of databases. It won't contain the text of a news story, but will know how to find text of a news story. You won't keep the high-resolution photographs here -- they'll be in your image archive -- but the Recycling Center will be able to look into your image archive, find the photo you want and deliver either a high- or low-resolution version.

The Recycling Center will be able to dip into all your other databases -- live news, photos, ads, pages -- as well as your archives of all these components.

Each component of our system of 2004 -- some familiar but changed, some completely new -- will work in concert with the others.

Each will have the resources necessary to put together not only its own primary product, but will also work seamlessly with other systems that are building secondary products.

In conclusion, I cannot emphasize how much work will be necessary to accomplish these goals. Today I challenge you, whether you come from the supplier community or the newspaper community: If we do not begin working on these components -- if we do not move away from our concept of a core traditional front-end and move toward the core of a Recycling Center -- one day we will not be the primary information providers in our communities.

The companies that better understand technology -- the Microsofts and the Bell Atlantics and the TCIs and the broadcasters -- will come into our markets and clean our clocks.

Remember those revenue pie charts: Are you willing to cede 50 percent of your revenues over the next 10 years to your competitors? If not, you better get a move on.

Start working now to usher in the end of the front-end -- and the start of the Recycling Center.

-- dmc

From THE COLE PAPERS, May 1994, Copyright (c) 1994, All Rights Reserved.