From print to e-mail: creating a database-generated HTML newsletter

Information Outlook, March, 2005 by Paul Yachnes

Sometimes trying to make a small change in the culture of your institution can be much more difficult than tackling a tricky technical problem or overcoming resource limitations.

[FIGURE 1 OMITTED]

So I discovered when I proposed converting, from print to electronic format, News Briefs, a daily print digest of newspaper industry news compiled from newspapers, Web sites, and magazines, and distributed to selected staff (figures 1 and 2). When I became manager at the Newspaper Association of America's (NAA) Information Resource Center (IRC) more than four years ago, my proposals to convert the digest to a nicely formatted electronic newsletter met with stiff resistance.

[ILLUSTRATION OMITTED]

The head of the Communications Department, to which the IRC belongs, stuck with the dogma "senior staff wants it the way it is." Likewise, the part-time staffer who put it together each day was content to cut and paste articles from various newspapers and magazines, print articles from Web sites, and then compile, photocopy, and distribute the digest to selected staff members. This process took at least three of her available five hours each day. The attitude seemed to be, "Why would we want to do it electronically, and wouldn't it be more work?"

[ILLUSTRATION OMITTED]

With changes in Communications Department management in late 2003 and early 2004, the opportunity arose to do things in new ways. Staff cuts in the IRC made it imperative to find a more time-efficient way to compile and distribute News Briefs. This time, when I proposed converting the digest to an electronic format, my idea was greeted with enthusiasm from IRC staff and senior management. They decided that the newsletter should take the form of an e-mail, containing as many full-text articles as possible and short summaries with links to articles for which (owing to copyright considerations) full text could not be reproduced. The digest was to be renamed NAA News. By eliminating photocopy expense and the time spent on distribution, we could make the newsletter available to all staff.

[FIGURE 3 OMITTED]

Planning and Design

Three main areas needed consideration: (1) copyright permissions for electronic distribution, (2) the design and usability of the newsletter, and (3) the technical requirements of efficient compilation and distribution.

1. At the time this project was initiated, the Copyright Clearance Center (CCC) photocopy license did not include an electronic distribution license (they've now been rolled into one), so we had to obtain one. We decided to attempt to get blanket permission directly from certain core publications not covered by CCC's electronic distribution license. For the rest, we would just include a brief article summary with a link.

2. I came up with a list of features I wanted the newsletter to contain: (a) a distinct and original nameplate; (b) a table of contents, including article headlines, bylines, sources, and publication dates; with internal hotlinks to (c) the full article, including a repetition of the information in "b" followed by the article body, or a summary and the URL; (d) hotlinks from the top of each article back to its listing in the table of contents; and (e) hotlinks from the bottom of each article to the top of the e-newsletter. Implementation of these features dictated that the e-mail be formatted as HTML, which as not a problem as it was for internal distribution only, and all staff used Outlook as their e-mail browser.

[FIGURE 4 OMITTED]

3. Since the daily newsletter was to be compiled by support staff with limited technical skills, I needed to make the process as simple as possible, with completely automated formatting. It was clear that it would have to be database-generated. Our library database software, Inmagic DB/Textworks, with its sophisticated report-writing capabilities, including its ability to incorporate HTML code, seemed fully up to the task.

All I needed to do was create a simple database and record input form into which support staff could copy and paste headlines, bylines, sources, dates, comments, articles, and links from a variety of online sources, and then create a report form to generate the HTML code. All support staff had to do daily was create and save records, run the report, and save it as HTML. The saved HTML file would then be inserted into a blank Outlook e-mail message and sent to a global address list.

Implementation, Phase I

Creating the database was easy and took little time; creating the report form was more challenging. It took several days of experimentation to get the result I wanted (figures 3 and 4).

A particularly knotty problem was that I could not initially get the desired format: a table of contents above linking to the complete articles below. The report would cycle through the set of article records only once, creating the table of contents. I could find no way to get it to cycle through a second time to insert the articles in order below the table of contents.

Once the report had arrived at the last record, there was no way to go to the beginning to pull out the full articles. After a few calls to Inmagic support, I determined that this was, in fact, impossible. The only solution was to redesign the database to incorporate all the articles for each issue in a single record. Since there would be a maximum of 10 articles per issue, this proved to be not too unwieldy and, most important, it worked.