Mixing Up Web Site Management

Maintaining a library web site is a huge chore. It's true that 90 percent of the material remains the same day in, day out. Our location looks pretty fixed. The services we offer remain the same. The online exhibits aren't likely to change soon. Our subject specialists review their material once every six months.

In fact, for much of my site, what I need isn't so much a content management system as a digital format preservation plan.

But it's the remaining ten percent of the site that gives me almost 100 percent of the grief. I'm changing some information every day of the week—sometimes more often. And it's not like it's easy to change. Some of it is hugely complicated, and one slip of the finger can maroon a library workshop to 11 p.m. on a Sunday instead of its rightful slot of 11 a.m. on a Tuesday. Hell hath no fury like an instructional librarian whose schedule you've messed up. I've learned my lesson: don't manage other people's information. Let them manage it themselves.

A corollary to this is that the more information is likely to change, the less you should have anything to do with it. As a web manager, your job is to rule over the site as a whole and to make sure that the various technologies play nice with each other. Let's lift the burden by identifying problem areas and the technology that can help alleviate some of the work.

I'm not advocating automation merely as a labor-saving device for web managers, but it's an incentive. It's not necessarily how I'd sell it to the rest of the "team," but it's important to recognize where the argument comes from.

More library information is going online; information that departments used to post on a board in a hallway is now finding its way onto our sites. It is important for those departments—those board-posters—to make the transition to a web-based publication system simply to ensure their own survival. It is equally important for those of us with information technology/web responsibilities to ease the way. The question is, where to begin?

As mentioned, content on a library web site is lopsided, with a lot of activity in some areas and little to none in others. One possible solution is a Content Management System (CMS). The idea is for anyone to create his or her own content, have it vetted by higher-ups, and then publish it in a highly organized and accessible manner. If only the content would manage itself; that's what people really want. Short of that we have CMS—or so the thinking goes.

The problem with CMS—at least with the big players—is that it follows a publishing or document-based model that may not reflect the workflow and information needs of a library web site. Also, the countless creative ways we might want to manipulate our bits and pieces of data may run up against the limitations of a typical "document engine." Here's an example: we want our hours to reside not only on the hours page but also on the front page, except on the front page we only want the hours for today. While we are still managing content, the standard document-centric CMS approach would fall flat. It solves the wrong problem.

This isn't to condemn all CMS solutions—just the heavy-handed ones. A far more nuanced approach is to have a mix; allow for traditional (i.e., manual) management in areas not subject to change while concentrating our scarce resources on areas where automation makes the most sense. This may involve a quick-and-dirty CMS or producing our own database solutions. The good news is that there are a number of options out there. A great introduction to the concepts of managing database-driven content can be found in "Managing Database-Driven Web Content" (netConnect, Fall 2002, p. 24–26).

Before deciding on the specific solution, identify the problem better. Imagine that a fairy godmother pops into the systems area and asks how she can relieve the maintenance burden of the library's web site.

"Well, fairy godmother, I spend an inordinate amount of time dealing with the subscription databases."

"Is that all, my child?"

"There are also the workshops and other library B.I.'s, which are constantly changing."

"In both these areas, my child, are the data submitted in a consistent form? Do you have anything to do with it before it hits the web?"

"Wow, FG, you sound just like a web developer! The form of the material is always the same. The only thing I do is throw it into HTML and put the thing up."

"Obviously, what you need is a utility to allow the content creators direct access to this information." She touches the machine with her magic wand and a password-protected administrative module is added with both a subscription database and a workshop registration application.

Bowing, she disappears in a puff of smoke. Too bad. I wanted to ask her to automate our hours page.

The moral of this story is to locate what on your web site represents the greatest activity. The higher the complexity of the information, the greater the need to automate. Uniformity of content is important. By automating activities like subscription databases, not only are you giving direct control to the content creators—something they'll appreciate—but you also create imaginative ways to deal with the information they submit. For example, if all we wanted was a listing of our subscription databases, we might not even wish to automate the process. But automation makes sense if we are going to break down the databases by subject, allow users to sort the databases, and let subject specialists have a direct say in how the material is arranged. News items could appear on a "news" page, but the title of each item—perhaps the first half-dozen—could also dress up one corner of the library's homepage.

Of course not everyone has a fairy godmother. Fortunately, many technologies have emerged to make the process of breathing life into an automation scheme far easier.

Certain backend issues have to be settled first. In architecting a database application, you're typically dealing with a database plus some sort of scripting language to communicate with that database. Both these aspects are decided by whoever maintains the web and database servers. Often the decision on what to use has already been made. There are also the parameters of what you are allowed to do in your particular situation. It matters little, for example, if you're okay with whatever scripting technology and database the IT people have chosen if you don't have access to either of them.

The tools themselves range from requiring very little scripting and database experience to needing a reasonable amount of knowledge. Many of the tools are low-cost or free. At the top of the category, of course, are proprietary databases costing several thousands of dollars, such as SQL Server and Oracle. Even here, your institution may already have access to these packages. On the other hand, for almost all the applications, there are free open-source alternatives.

But let's say you want the least technical fuss. You could set up your own news application by simply going to blogger.com or some other blogging site. It's true this is a CMS solution, but it's one that specifically meets library needs. Once you've hooked it up, Blogger will allow you to not only maintain a news page but to syndicate the information for use elsewhere on your site or on the site of others. It's fast and cheap.

Another way is to take advantage of Dreamweaver's database capabilities. Formerly you had to pay extra for this, but since Macromedia came out with DreamweaverMX, you have the ability to create effective (albeit limited) database applications in a variety of scripting languages. This is perfect for basic tasks like generating a brief list of items that users can click on for more information. In the context of a library, you could have a subscription database page that shows brief titles of databases. Users could click on these to get fuller descriptions, with the information coming out of a database. With Dreamweaver, you could also create an input page where the original subscription database information is added.

Dreamweaver can handle scripting languages such as ASP, JSP, PHP, and CFM. If these acronyms sound like nothing but alphabet soup, don't worry. Your systems administrator may already have chosen one for you.

Scripting is typically run as part of the web server application. What happens is that the web server grabs up a page, and if it identifies a bit of it as script, it invokes a scripting interpreter to handle it. You can add almost any interpreter to a web server if you really want to. For example, Microsoft's IIS will run happily with Apache Software Foundation's PHP or CFM (Cold Fusion).

PHP and CFM are considered user-friendly scripting languages. There's cool stuff being done in PHP these days, so if you are free to choose, take this into consideration. It also helps that a million developers are using PHP. If not, they're probably using Cold Fusion, which has a reputation for being easy to use, although it's entirely the product of Macromedia and not open source like PHP. JSP (Java Server Pages) is fine if you're more interested in the programming side of life.

What these scripting languages have in common is their ability to connect to a database. Perhaps the first thing you'll hear about PHP is its ability to work with MySQL, a very popular open-source database. The PHP/MySQL combination is in fact one of PHP's chief selling points. These scripting languages can actually connect to just about any database from Access on up. In fact, if you have some application in mind that might not necessarily get a lot of traffic, plain old Access is perfectly acceptable.

If you anticipate a bit more robust traffic, there are open-source possibilities like MySQL and PostgreSQL. Each has its advantages and disadvantages. Don't let the "open source" moniker put you off. Both drive some of the most intense commercial sites out there. Where money is tight and ambitions are high—even modestly high—these may be the way to go.

By using technologies like these, we dramatically enhance how information is produced and used on our web sites. We move the center of creation nearer to its source while at the same time tailoring it in countless innovative and useful ways for the end user. That's the purpose of an effort like this. The tools at our disposal are getting better all the time.