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.
