The webmaster, once seen as a hero and magician, is now in danger of being viewed as a bottleneck. No lone person, or even a central office, can be responsive enough to keep today's complex higher education websites stocked with up-to-the minute information. On the other hand, if dozens of individuals and offices create their own web materials without coordination, a website can splinter into unnavigable chaos. This dilemma is motivating many savvy webmasters to start moving their institutions in the direction of web content management software (WCMS).
There are literally hundreds of products that offer some version of web content management. You can find inexpensive packages that provide a modest environment for coordinating contributions to a website by a handful of authors. At the high end of the scale, ambitious enterprise content management systems aspire to integrate databases and content types that go far beyond static web pages. Those systems can run up project costs well into six figures and require extensive technical resources. There are also quite powerful systems available under open source agreements. (See box for a list of representative vendors.)
As with so many IT projects, when you set out to adopt web content management, you are probably also initiating cultural change, so include the stakeholders right from the beginning and secure commitment from the top administration. Start with an assessment of your needs and agree on the problems that the new system must address. You will find it much easier to sort through the software options if you set limits beforehand on how far you really want to go.
Here are some suggestions to help you set expectations and match them with the product features you will encounter.
The most fundamental capability of a web content management system is to create a secure, easy-to-use, collaborative workspace. You need to be able to parcel out the responsibility for editing certain parts of the website, while preventing unauthorized access to the material. Some systems provide their own internal systems for assigning usernames, passwords, and privileges to the collaborating editors. That's fine if the number of people involved is relatively small and stable. But if you have dozens or hundreds of users, and there is constant turnover, maintenance becomes a major task--maybe even a new bottleneck. In a large environment, you probably already have a campuswide authentication mechanism, like LDAP, Kerberos, or Microsoft's Active Directory. If so, you might restrict your search to systems that integrate with your flavor of authentication.
As you look more closely at the steps involved in posting new web material, you'll find that users play distinct roles. The more sophisticated WCMS offerings reflect this. In an Admissions office, for example, an associate director might be responsible for writing information about an upcoming campus visit, which then has to be approved by the director of Admissions before being posted by the department's technical coordinator. In another setting, the same associate director might have full control over creating, approving, and posting material on another page for a program that she runs herself.
Managing that level of complexity is made much easier if the WCMS supports the concept of roles. A person might be assigned the single role of author for one web page, while carrying out roles as editor or approver for another page. That way, a person who needs a high level of access in one area is not given the master key to the whole system. This level of sophistication in assigning privileges could be vital in one institution, and maddening overkill in another.
One of the reasons that people got so dependent on the webmaster in the early days was a four-letter word: html. The appearance of WYSIWYG (What You See Is Slightly But Aggravatingly Different from What You Get) web editors like Macromedia Dreamweaver and Microsoft FrontPage make it easier for nonexpert users, but still come with their own learning curves.
If content creation is to be shared by a large number people across campus, there has to be an easier way. If most contributors will just be plugging plain text into prebuilt templates (adding new events to an events calendar, for example), then a fill-in-the-blanks screen will make it easy to do the job without much training. It's even easier if contributors can simply use a form in a standard web browser, without having to learn any special software. This simple approach works well for letting faculty and staff maintain their own personal web pages--as long as they are satisfied with following a standardized and fairly simple format.
If the contributors will be allowed to be more creative, then your WCMS product has to incorporate an easy-to-use layout editor of its own, integrate with third-party tools like Dreamweaver or FrontPage, or allow importing of formatted material from desktop applications like Microsoft Word or Excel.
One of the main reasons for adopting a WCMS is to achieve a consistent look and feel across the site. A powerful WCMS lets you establish a framework that will automatically be applied to entire groups of pages. You will want a system that stores the common framework in one place and provides an automatic way to update it for all the pages that use it. Otherwise, a slight tuning of the navigation bar could require finding and changing every web page where that particular element appeared.
There is really a paradigm shift that comes along with thinking about deploying a WCMS. It means that your institution has moved beyond seeing its website as a collection of independent, static pages. Instead, the institution is coming to the realization that the website is a complex collection of data, vital to the running of the institution and communicating with its constituents. This collection of data needs to be properly categorized, sorted, retrieved, updated, and presented in different formats.
That is why a top-level WCMS treats web material as a database and even stores metadata along with the material that is being presented in the web pages. Metadata includes information about the author, the authority who approved the material, previous versions of the material, the creation and edit dates, embargo or release dates, and even the date that the information expires and should be removed from the web.
In some WCMS environments, the web pages are not stored as static files, but are generated dynamically when they are called for. This makes it possible for the same material to be formatted differently depending on the context that it will be presented in (for instance, streamlined versions of the same material for printing or for display on a handheld PDA.)
Even the best tools won't be easy for your users if they don't run on the platform they use every day. This is a more serious consideration for campuses that use platforms other than Windows and browsers other than Internet Explorer. Further, your technical support team may also have more trouble supporting systems that are built in technical environments that they don't regularly support. Are your tech people at home with J2EE, PHP, ASP, MySQL, or whatever technologies this particular package uses? These kinds of technical choices may quickly narrow the range of systems you consider.
Web content management software can be expensive to buy, set up, and maintain. But the return on investment can be substantial, making it possible to tame an unruly website. After all, managing the content of your website is not optional. Whether you do it by hand or automate it with web content management package depends on how complex your site has become and whether the traditional manual methods are likely to scale for the future.
John Savarese is Consulting Principal at Edutech International, (www.edutech-int.com) a consulting firm providing information technology services for higher education.