Open Menu Close Menu

Web Publishing on .EDU for the Long Haul

College and university Web sites have become vital communications media between the offices and departments of an institution and constituent audiences. In order to maintain their credibility, timely publication of online content is critical. But how can a large and growing volume of time-sensitive information be published online quickly and reliably at a busy institution? How can a university's Web site support the needs of numerous academic departments and offices?
One popular approach to content management is to designate a Web developer or team of developers as "proxy editors" who process the content centrally, rather than through the departments that actually "own" the content. Information is submitted to Web specialists, who, in turn, may edit and format it for publishing on the Web site.

Publishing on the institutional Web site can be managed with a range of strategies, from purchasing high-end, full-featured content management systems, to developing in-house systems and services, to coordinating individual departmental development efforts. Here, two seasoned planners consider the possibilities.

However, as Web sites grow, this familiar publishing model proves to be unsustainable. Workflow between departments and Web masters tends to be inefficient and can become bottlenecked. Technology staff time is spent on non-technical editing tasks. Requests pile high, work queues become overloaded, departments become frustrated, and technology talent can become burned-out.
A lack of motivation for maintaining the information on the site can also result, because the technology staff d'esn't necessarily understand the "big picture" and departmental staff feel that they have "washed their hands" of the information. Ultimately, personnel time is misused or wasted, and the results will not meet the expectation of timely content publishing.

Decentralizing the Web Publishing Process
Web publishing technologies have matured such that content management can now be distributed among those institutional groups that typically generate content. Yet, adopting a distributed approach requires a change in the way institutions think about information ownership and online publishing.
No doubt, many of us have witnessed this change as growing pains—really the growing pains of an information revolution. In departments new to Web publishing, putting content online may be viewed as requiring the technical skills of a Web master, or departments may be otherwise hesitant to manage information that is presented on the institution's Web site. Departmental administrative staff may discover, much to their surprise, that they have suddenly become Web content managers.
Resistance also comes in the form of a perception that staff lack the skills to take on the task of content management or development. Given such poorly defined roles and responsibilities, a content management strategy can end up with a less than desirable result: Web content that is stagnant or underdeveloped; the site seen as something that "we just don't have time for."
Addressing perceptions and defining roles from the start will lay a better foundation for a successful content management system. When an organization settles on decentralizing the Web publishing process, a carefully planned transition should include these concerns among the following important "to do's": determine the ownership of information and the responsibilities of content managers; establish a support capacity; develop training programs; work to identify and overcome negative perceptions; adhere to ADA and W3C standards; and choose appropriate technology tools.

Tools for a Partnership
Some technical tools have evolved that improve the flow of information between content owners and Web sites, creating a streamlined publishing process. Typically, for the content editor, these tools require only rudimentary computer skills, such as word processing and familiarity with a Web browser.
A wide range of tools are available, from large-scale content management systems, to stand-alone Web publishing tools, to systems developed in-house by Web staff, which may incorporate a number of off-the-shelf products. Content management systems can range from fairly simple with just a few features, to very complex with features adaptable to larger, more formal information management needs. Full-fledged content management systems, with full-featured content creation and publishing tools, can range from $3,000 to $100,000 or more. Interwoven, Vignette, Eprise, and Spectra (Macromedia) are just a few examples. In some settings, desktop tools for Web publishing, available for a few hundred dollars—Macromedia Dreamweaver and Microsoft FrontPage are examples—can be employed in a content management strategy.
At Clark University, a partnership now exists between the content managers and the Web development staff, software trainer, and help desk personnel. This has sometimes been a delicate balance, in that while the institution expects departments to follow design and template standards, it also wants to have each department or office maintain its own site. But, the shift in responsibility for content management from Web master/manager to departmental secretaries and others has for the most part been a success at Clark.
The problems we faced are common: lots of people, lots of time-sensitive information to get out there, and a small number of staff who know how to make it happen. A big part of our solution is a back-end database system, which we developed in house. In our case, the Web developer works with Cold Fusion (though it could just as easily be Perl, PHP, or ASP) to custom program a content management system that allows the public Web pages to parse out database records. An internal administrative page or database application is available to the content owner, so that s/he may have access to make edits to the database records and thus to the content that is seen on the public Web site. Our situation isn't isolated—other institutions have found similar solutions to the information flow/bottleneck problem, seeking a middleware approach to bridging content owners and the Web site.
Use of new publishing tools elevates the roles of all concerned. Content owners can publish information instantly, without consulting a third party. Web professionals can spend time honing their expertise and developing complex applications rather than making incremental edits to text. Content managers may enhance their own experience by becoming familiar with online publishing. The institution as a whole is simply more involved and accountable for communications on the Web. While these tools are no panacea, they can make a difference when a concerted effort is made within the context of a partnership between the content owner and technical support staff.

Browser-Based Editing
When we refer to content management systems, at least from the point of view of the content manager, we are really referring to browser-based editing. Tools range from full-scale workflow-oriented systems to widgets for smaller-scale use that simply take information from the browser of a content owner and insert it into a database record. In a database system, Web site visitors see a Web page that appears as any other Web page would, with little or no indication that the content is stored in a database.
Larger scale content management systems, such as Spectra (from Macromedia) provide additional features such as workflow approval processes and role-based security. In these cases, a content manager for a given department could reserve final approval for the pages that she or he reviews from others in the department who have submitted them into a Web-based approval queue.
One significant advantage of a database system is a single point of deployment of content. A single master copy of all the important data resides in a database, and that data is used for every occurrence of a given item throughout the site. Thus, corrections only need to be made once—in the database record. Additionally, because of the incorporation of site templates through which data is fed, content managers are free from the need to insert Web site design elements.
Supporting a browser-based content management tool is straightforward, though content managers may find themselves at the mercy of what the Web development staff can or cannot do in terms of customizing features for the publishing environment. Similarly, this kind of system will be inherently less flexible, because it imposes a data structure throughout the site.

Publishing via a User-Friendly Application
When we speak of easy-to-use Web publishing applications, such as Microsoft FrontPage, we are in an area that is already familiar to many. There is a comfort zone in using these kinds of tools. Where the highly structured content management application constrains what publishers can do, the user-friendly publishing application offers capabilities and freedom. Whereas the content management data structure would not generally offer content providers the option of creating an interactive form themselves, applications like FrontPage allow users to easily build them on the fly. FrontPage even offers special wizards that allow users access to such powerful capabilities as creating discussion forums or slide show presentations.
But the inherent freedom and capabilities of the Web publishing application may also seem to be an albatross around the necks of support staff. Such applications are powerful, and though they are easy to use, the technical support requirements for a large deployment of FrontPage should not be underestimated. The burden has merely been shifted: The Web developers may be free from building some interactive forms, but "easy to use" being a relative term, we know that the support staff will receive their fair share of calls.
Additionally, while the institution may have standard organizational templates and requirements for Web site design "look and feel," content owners using a desktop publication tool may choose to ignore them and decide that they can be "en loco" Web designers. Blurring the boundaries between content providers and Web designers may mean that the Web department will have to manage more support issues and reconcile the design conflicts that may arise.

Wise Choices
How and why you might deploy a given system is a matter of assessing your needs and balancing these with your capabilities of supporting a given application. Choose an application that you can not only afford to purchase, but that you can also afford to support. You might consider whether you have development staff who could both develop, in house, and support a content management system. Do you envision a tightly integrated formal structure for your site? Or instead, do you foresee your content providers as a community of interdependent power users? Depending on how you answer these questions, a system can be identified that best meets your needs and is sustainable for the long haul.

Chuck Wyatt ([email protected]) is manager of Web services, and Cheryl Turner Elwell ([email protected]) is director of client services; both helped to develop the content management strategy at Clark University.

comments powered by Disqus