Imagine this: There you are in New Orleans, sitting in K-Pauls or some other fine French Quarter eatery, having consumed a fabulous meal (on your expense account, of course). Lingering over coffee laced with chicory, you and your table mates review what you saw on the NEXPO show floor. It is Saturday, June 21, 1997.

Databases

Probably the biggest news out of NEXPO'97 is the preponderance of database systems. There are systems that encompass the entire newspaper--providing interlocking information about classified, display, circulation, press configurations, news and graphics--and there are simpler systems that merely track elements or pages.

Some of the braver souls amongst the suppliers have even ventured forth with "object-oriented databases" as opposed to the now-traditional "relational databases." The problem with relational databases in a publishing environment, it turns out, is that they don't work well with large amounts of data--like stories or ads or pictures. Either the database must point to these data (causing performance issues because of the server's file system) or embed these data (causing performance issues because of the overhead of a large database). Object-oriented databases, on the other hand, are designed to embed "objects" of data--like stories and ads and pictures--into the database, which is optimized for such large chunks.

So there is now a debate on the floor about which approach is better: Some suppliers are extolling the virtues of relational databases and some are singing the praises of object-oriented databases. Unfortunately, most salespeople don't understand the differences and you get entirely different answers from every supplier.

New Front-ends

Off the show floor, two suppliers are demonstrating editorial and classified front-end systems that have skipped the client/server model and moved directly to an intranet model.

These demonstrations--which depend heavily upon the Hypertext Transport Protocol (HTTP) and the Java programming language used on the World Wide Web--illustrate two important concepts: first, the machine sitting on a worker's desk doesn't have to be a specific brand or run under a specific operating system; second, a central database (see above) is the key to the newspaper of the future.

These systems have both whiz-bang features (gathering all the pictures, text and graphics for a story into one window) and a much lower cost (as most of the client software is based on inexpensive Web browsers such as Netscape Navigator and/or Microsoft Internet Explorer).

The most interesting thing about these systems is that they were created by companies that have no previous background in front-ends. The traditional front-end suppliers, who had a difficult time moving from proprietary to client/server, have made too large an investment in client/server to abandon it quite yet. So the buzz about these systems has caused the traditional suppliers to heap scorn on them. "Do you want a system intended to publish a newspaper," one asks, "or do you want a system intended to look at a Web site?"

Another trend in front-end systems includes automatic routing of material (ads, stories) to both print-based products (i.e.: newspapers) and on-line products (i.e.: the Web). In classified systems, Web "zones" are now prevalent and ads can be spun off easily to the Web, allowing for easier billing.

Productivity Tools

Into this catchall category, we throw two interesting tidbits:

• A couple of suppliers have come to the conclusion that traditional page-layout tools are not necessarily very efficient when designing the vast majority of newspaper pages. Since most pages consist of a stack of ads that take up a large portion of the page--leaving only a small fraction for news content--and since most papers are designed using a highly complex set of rules, suppliers have created automatic editorial dummying systems that scan a page, scan an editorial budget and offer suggestions about how to lay it out. These automatic editorial dummying systems are being offered both for proprietary page-layout solutions and for those based on QuarkXPress.
• Because of the industry's reliance on Microsoft Word as a text editor, there are dozens and dozens of Word "macros" being offered. These bits of code take away bunches of Word's functions (such as footnotes and page formatting) and include bunches of functions formerly found in proprietary systems (such as single-key and large search-and-replace operations). Not only are suppliers that sell systems based on Word marketing these macros, but so are small, boutique businesses that are usually offshoots of the traditional suppliers.

Ah, but these are merely fantasies of a Las Vegas-addled brain. With the exception of eating at K-Pauls, none of this may come true. To get to this point, suppliers would have to fully understand the needs of the newspaper industry and, of late, they have not.

But in the event some of these whimsical projections do come true, if you buy the dinner, I'll buy the chicory-laced coffee.

Cole is a San Francisco-based newspaper consultant and is editor of The Cole Papers, a monthly newsletter on technology, journalism and publishing. E-mail, dmc@colegroup.com; phone, (415) 673-2424; fax, (415) 673-2449. The opinions expressed are those of the author and not necessarily TechNews or NAA.

TechNews Volume 2, Number 4: July/August 1996

Return to July/August Home Page
Return to TechNews Topic Index

©1997 Newspaper Association of America. All rights reserved.