Publishing a few pages on the Web is embarrassingly easy. Getting a group of people to do so effectively is difficult. And getting many groups to create a combination of static and dynamic pages, tracking revisions, setting up workflow, and making the framework scalable and secure is nearly impossible.

This is illustrated only too well at Gannett Co. Inc., which publishes USA TODAY, USA Weekend and dozens of regional publications. Recently at Gannett headquarters in Arlington, Va., I examined Web content management packages that could enable easier and more consistent publishing and design of Gannett’s intranet content.

Gannett’s early experiments with designing and maintaining departmental intranet sites used readily available Web authoring software that lacked the ability to apply standard design templates.

Gannett is considering standardizing on a set of styles so that all its business units can function similarly. The goal is a more efficient Web structure and a better user experience, said Gannett IT architect Gary Gunnerson.

Although many companies’ sites will not be as complex as Gannett’s, and many others will be more so, every company’s Web publishing system should allow designers to maintain a consistent look and feel across company sites without restricting the freedom to produce innovative content.

During a three-day Shoot-Out,  Gunner son, Gannett IT staff and representatives from USA TODAY put six Web content management packages to the test using Gan nett’s intranet content and requirements. Tested were Cyber Teams Inc.’s Web Site Director 1.3, Dyna Base 3.12 from eBusiness Technologies (a division of Inso Corp.), Future Tense Inc.’s Internet Publishing System 2.1, Info square Corp.’s OpenShare 2.01, Mortice Kern Systems Inc.’s Web Integrity 2.4 and NCompass Labs Inc.’s Resolution 2.1.

Each package met some of Gannett’s requirements, but none was up to snuff on handling them all.

Notably absent were Interwoven Inc. and Vignette Corp., both of which typically do not allow their products to be reviewed.

The term “content management” has been adopted by almost every vendor of a software product that has something to do with HTML. Vendors are increasingly taking their older technologies, adding support for Extensible Markup Language and then repositioning them as content management systems. This holds true for companies ranging from object database vendors such as Poet Software Corp., to large-scale database vendors such as Oracle Corp., to Micro soft Corp. with Office 2000.

None of these companies’ products have much to do with content management, however, because they fail to accomplish a major task of a true content management system-distributing the management of Web development. Control over content is fairly routine when one person or a small group creates content for an entire site. But as more people are involved, the difficulty of managing the flow of data is magnified.

In their most basic form, Web content management systems should allow each content producer to create pages and feed them to the publishing system. The system should have customized and automated checks and balances to ensure that pages get placed correctly, that navigation trees are created and maintained, and that the appropriate people control the process along the way.

To make this happen, good Web content management packages separate content (written material, images, streaming audio and anything else that makes up Web pages) from presentation of content, and they include strong workflow capabilities.

Most of the packages evaluated lacked strong workflow capability, a detriment considering Gannett’s-and most companies’-need for such structure. One of Gannett’s top requirements sent to Web content management vendors prior to the Shoot-Out event was extensive workflow capabilities.

But workflow is only one of a long list of features Gannett is looking for in a Web content management solution. These items, which define how Gannett works today and where it wants to be, include the ability to handle multiple site views, a search engine and support for multiple open platforms.

In the deployment of a web content management system, scalability can be anything from a nonissue to a major concern.

On most corporate intranets, where as many as 1,000 simultaneous hits are rare, a single Web server running a content management application can easily serve the entire intranet. In such a setting, the capacity of the Web content management application is generally a much smaller concern than its stability.

Scalability is a primary concern, however, when a firm deploys content management on a Web site, particularly an e-commerce site. I have seen several cases where sites either crashed completely or selectively lost content because of problems with their content management systems.

There are several steps site managers can take to ensure that systems scale to meet their needs. The simplest is to install the Web content management application on a different server than the one from which the Web site itself is deployed. Most of the applications tested in a  Shoot-Out can be run on a staging server or be configured to export content to an external server.

The benefit of these setups is that the content management is disconnected from the Web site it manages. If the management application crashes, availability of the Web site and its pages would be un affected.

Also, since many content management applications are tied to specific operating systems and Web servers, this approach lets the Web site run on any system and Web server.

Loss of benefits

On the downside, this setup removes many of the potential benefits of a Web content management system. Changes have to be regularly migrated from the server managing content to the server running the site, increasing the need for administrative intervention. This can be especially troublesome for a company specializing in up-to-the-minute delivery of content, such as a news organization.

Running the content management system on a separate server also complicates the process of making quick changes to incorrect content on a site. Corrections either must be delayed until the content management application updates the site or be made outside the content management system.

The two most scalable packages we saw in the Shoot-Out were DynaBase from eBusiness Technologies (a division of Inso Corp.) and FutureTense Inc.’s Internet Publishing System.

IPS runs on top of Netscape Communications Corp.’s powerful Netscape Application Server. Through that server, the system maintains load balancing, system failover and session management, ensuring high performance and solid stability.

DynaBase works similarly, but it doesn’t directly use an application server, relying instead on what it calls Web Server Plug-ins. The plug- ins reside on the Web server and communicate with a separate system running DynaBase.

Another option is to scale content management applications by deploying multiple systems and instances of the application. However, content management applications are priced by server and by CPU, so a business could easily spend $500,000-mostly on software licenses-to build a scalable system.

Businesses must evaluate their individual needs for scalability. An intranet crash, while inconvenient, is rarely catastrophic and is almost never caused by high traffic loads. On the other hand, when a Web site goes down, especially an e-commerce site, the company loses money every minute.