The Virtual Press Room (VPR) was a docbase built by vendors and their public relations representatives. It enabled these groups to transmit press releases electronically, rather than by fax or snail mail, to the editorial group. These documents, in aggregate, record the entire history of the high-tech industry. Although there are services that collect and publish this material, such as PR Newswire (http://www.prnewswire.com/), their scopes are broad. Every trade magazine has its own editorial group, its own readership, and its own natural affinity with the vendor community. The Virtual Press Room created BYTE-specific bindings among these groups.
As Table 5.1 shows, the VPR was an example of a docbase whose repository format coincided with its delivery format. That format was simply HTML, written by the script that handled the VPR’s input form. In Chapter 6, we’ll see how this kind of script can receive semistructured information, validate it, enable users to preview the docbase page to be built from it, and finally store that page. Associated with the VPR were some other scripts. One built the pages that navigated the part of the docbase that was published on the site. In Chapter 7, we’ll look at ways to build navigational systems that support both sequential and random modes of access to a docbase along multiple dimensions. Another script watched for new entries to the docbase, summarized them, and routed them to editors. We’ll see an example of this kind of notification system in Chapter 12.
Let’s review how the VPR created bindings among vendors, editors, and readers.
Press releases that target editors at trade magazines are not only numerous, they are highly duplicated. When it’s unclear who should receive a press release, the tendency is to broadcast it to everyone. That’s expensive for the sender and annoying to recipients. The Virtual Press Room brokered these communications, presenting all editors with a daily summary of new releases.
For vendors, the VPR created a group communication space that worked as the conferencing spaces that we discussed in Part I can work. It freed contributors from the obligation to identify correct recipients or to limit the scope of their messages. Any editor on staff might, for unpredictable reasons, want to follow up on any particular press release. In a group communication space, these serendipitous connections can happen.
In the daily or weekly summaries emailed to editors by the script that monitored the VPR, new entries appeared as clickable titles. A recipient could scan a batch of new entries and, if interested in one of them, click through to its docbase page.
This aspect of the VPR echoes another theme from Part I. In group communication, it may be appropriate to push messages at people to make sure they know about some item of information. But such messages need not necessarily tell the whole story. A headline or title is often the right way to announce that more information is available, provided that the announcement empowers the recipient to pull the whole story.
The email summaries of new VPR entries worked like list server digests. This technique echoes another Part I theme. In groupware environments, people are saturated with message traffic. Like a docbase, your inbox ought to layer the information it presents to you. At the top level, you’d like to see as few messages as possible. You’d like those messages to show what’s important and hide the rest.
The VPR cut down on message traffic by collapsing a day’s or week’s worth of entries into a single digest message. And it layered that message by presenting only clickable headlines. Each headline contained just enough information to enable a recipient to decide whether or not to click through to the next level—product name, company name, category, summary.
Trade magazine editors receive truly frightening quantities of press literature every day. When an item relates to a current assignment, it will be plucked from the pile and used. But what if it relates to a future assignment? The odds that a press release will be remembered, searched for, and found two months after its arrival are very slim. Indexed by company, product, and date, and also full-text searchable, the VPR docbase took care of the filing that busy editors had no time for.
The VPR docbase lived mostly in private web space, visible only to editors. But submitters could opt, for a fee, to move their announcements to public web space, where they were integrated into the BYTE site’s navigation and search systems.
As we saw in Part I, it’s not enough merely to create differently scoped zones of communication. Groupware should also enable communication to flow among these zones, crossing boundaries when it’s appropriate to do so.