SUBSCRIBE NOW!

Vol. 28 No. 3 — March 2008

I’m the systems librarian for the Advanced Technology Solar Telescope (ATST), a project for the National Solar Observatory (NSO) based in Tucson, Ariz. The project is designing a 4m (13.12') solar telescope that will begin construction around 2012; we have recently passed a major review by the National Science Foundation and hope to receive construction funding in the next fiscal year. The project staff is on the small side—fewer than 40 people—and all my services are digital (although I do buy books for the staff at their request).

Standing Still

A large part of my responsibilities involves running the website, which I’ve been doing with an “if it ain’t broke, don’t fix it” approach for the past several years. (I’ve been coding HTML “by hand” using eMacs on the server.) As part of the preparations for the previously mentioned review, we thoroughly revamped the design and layout of the website, added a ton of supporting documentation (in PDF), and streamlined the user view. This meant, of course, that I had to edit every one of the hundreds of pages—and I was the only one who could do the work because of the way server access was set up. Since a large number of the edits were designed to make the layout of all the pages uniform, there was a lot of repetition. It even became a physical problem—after days of clicking, my hands were cramped!

When you make a couple of small tweaks on a largely static website every day, it’s easy to say, “Oh, I’ll pull it all together later.” Each page was still largely laid out using tables; in order to have a somewhat consistent header and footer with what I was using on the server side this included calling supplemental HTML code. The cascading style sheet, such as it was, was extremely kludgy and not very efficient at all. I knew something would have to be done eventually, but I also knew it was a huge job, so I kept putting it off.

Starting to Move

As you might imagine, spending all day, every day, for a month hand-editing all of the pages really brought home to me that the time had come to pull it all together; I couldn’t postpone the job any longer. So, in the lull that followed the review, I began looking into content management systems (CMSs), specifically ones for website control. A CMS is generally used to create, control, store, and publish information. In addition, as Wikipedia points out (http://en.wikipedia.org/wiki/Content_management_systems), content management systems “are deployed primarily for interactive use by a potentially large number of contributors.” This is exactly what we needed. I began with a list of what I wanted a system to do:

• Easily implement a consistent template and design that could not be changed by the regular users

• Increase functionality of the site without having to learn a new programming language

• Increase collaboration among staff members

• Allow more users to make changes to pages

• Engage staff members in their public information

• Be easy and as intuitive as possible for staff members to use

Our initial plan had two points: It couldn’t cost very much, and it had to be compatible with the existing systems (Linux-Apache-MySQL-PHP, aka LAMP). After doing a bit of rough research using past issues of Computers in Libraries, Library Hi-Tech, and basic blog and web searches, I knew this was too broad a base to start from. I had to define some “must have,” “should have,” and “nice to have” features that would allow me to do some significant comparisons. (See Table 1.)

I also had to answer the question of whether to use a more “traditional” CMS or a wiki. Both had very strong possibilities, and I’d seen examples of both in action. More digging needed to be done!

Energy on the Rise

I sent out inquiry emails to a bunch of tech librarian listservs, such as Web4Lib and SYSLIB. I also did searches on websites such as Experts Exchange (www.experts-exchange.com) (which I already belonged to for different reasons) and TechRepublic (http://techrepublic.com). I then learned about cmsmatrix.org and wikimatrix.org, which let you input your search criteria into a huge form that will then return the most likely candidates. I started with the “must have” list and ended up with a very large list of possibilities:

My first reaction was a bit of astonishment—I hadn’t even heard of most of these! I cycled through the matrix several more times, adding the “should have” and “nice to have” lists. I ended up with nine reasonable suggestions. The next step was to dig into each of them; I printed out a large chart (40"x60"—almost as long as I am tall), hung it on my wall, and began weeding the choices down.

I based exclusions on too many missing functionalities (which also led me to the realization that you can’t take the cmsmatrix results as gospel), hidden fees (some that advertised as no cost were only no cost for one user), currency of support (one package hadn’t had an update in almost 2 years), required database underpinnings (even though I’d specified MySQL, an Oracle package snuck in), reports of others on ease of installation (very important to me, as I’d be the one installing and administering it), reports of others on ease of use (for my staff), and a short evaluation on another valuable website, OpenSourceCMS (www.opensourcecms.com). This site is highly recommended for anyone embarking on a project like this. OpenSourceCMS actually runs demos of hundreds of PHP/MySQL applications and allows users to be the administrator of any of them. Each system is deleted and reinstalled every 2 hours, so it’s always “clean” and ready for anyone to try out. I used it quite extensively for the weeding process. This enabled me to get it down to four final candidates: Drupal (www.drupal.org), WebGUI (www.plainblack.com/webgui), TWiki (www.twiki.org), and MediaWiki (www.mediawiki.org). The next step was to install these locally and for me and a small subset of my staff to test them.

Getting Dynamic With Drupal

The Research Experience program at the NSO gave me a spare Linux box to use as a developmental server; the first thing I did was upgrade it to CentOS 5 (CentOS, www.centos.org, is a freely distributable, open source version of Red Hat Linux) and make sure the latest versions of Apache, MySQL, and PHP were installed and running. All four possible systems were very straightforward in their basic installation process. In general I would say they were uncomplicated, but they do require access to the server and administrative rights. My test committee comprised two engineers, a scientist, and an administrative assistant (along with me). What I asked each of them to do was to log into the site (after I’d set up accounts for them), poke around on the pages I’d created for test editing, try out the editor, add an image, create a new page, then report back to me with comments, complaints, and requests for added functionality. When testing the wikis, several committee comments along the lines of “it’s too complicated” and “I don’t like the editor” struck them both from the running. When it came down to WebGUI and Drupal, they were judged to be equally straightforward, but I ended up choosing Drupal for three reasons: 1) There were several other libraries using it to run their websites, 2) it had a vibrant and active user community, and 3) it seemed to provide more flexibility in add-ons. Once this decision was made, it was time to start having fun!

I wiped the basic test installation and did a fresh installation of the latest version of Drupal, which was 4.6 at the time; then I started browsing the add-on modules and themes. Talk about bewildering! There are so many different modules to do so many different things, sometimes even multiple modules to do varying degrees of the same thing—it was pretty wild. I had a few problems getting some nodes (which are the various “blocks,” such as books, images, pages, etc., that make up the website) to display the way I wanted them to. I sent another inquiry to the Web4Lib and SYSLIB listservs and heard back from several folks who gave me very useful suggestions and tips. One of the folks I heard back from is a consultant for the Cherry Hill Co., which provides Drupal setups to libraries. I decided to stop trying to reinvent the wheel and hired him to be my consultant as well. With his gentle guidance, I was able to work through most of my problems. Some tips I learned, for example, are that it’s much easier to find a display theme you like and tweak it a bit to match what you need than to build one from scratch (I ended up modifying the NoProb theme). It’s also very important to install your themes and modules into the /sites/all/* directory and not into the top-level modules and themes directories.

As I said before, there are a mind-numbing array of modules to choose from. One thing I like very much about Drupal is that the modules are very easy to install and try out (once you make sure you’re installing into the correct directory). If you don’t like them, they’re very easy to uninstall as well. After lots of experimentation, these are the modules I have installed and kept:

• Front Page—This allows the front page of a site to look completely different from the rest of the site.

• Image—This allows uploading, resizing, and viewing of images. It’s required by several other image-related modules:

• Image Attach—This allows attaching images to other types of content.

• Image Gallery—This sorts and displays images based on categories.

• Image Import—This allows batch importing of images.

• Image Assist—This allows for inline images.

• Backup—This assists in backing up the Drupal installation itself.

• Glossary—This allows you to set up and define a sitewide glossary of terms, abbreviations, acronyms, or anything else you’d want.

• IMCE—This is an image and file uploader that supports subdirectories and sharing across the site.

• Nodeaccess—This provides access control on an individual node basis.

• TinyMCE—This is a rich WYSIWYG editor for content.

I know there are many more modules out there that will assist me in my continuing quest to get the site perfect; there are also a few glitchy bits that I’m trying to find solutions to, such as figure captions in book pages. But, as of this writing, the site is 80% populated with data from the live website. It visually displays the way I want it to, and I’m well on the road to setting up the various restricted areas of the site. We’re on schedule for going live by the end of January 2008.

Some of the lessons I’ve learned on this journey follow:

Don’t be afraid to ask for help, advice, or input. What other folks know can help you keep from banging your head on the wall repeatedly. Check the forums! If someone else is having the same problem you are and has posted about it, you can get an answer right off the bat.

If you want a turnkey system, Drupal is great. The basic site was up and running the same morning I installed the software package. It’s the tweaking and data ingestion that take all the time and effort. If you’re starting from scratch rather than reinventing your website, even that part is easy. Plus, for those of you who may be looking for a more complete tie-in to your library catalog, the Drupal project has just released a MARC module.

Customization is good. If you’re going to have users providing data for the website who are most familiar and comfortable with Microsoft Word, for example, it’s completely worth the effort to tweak your WYSIWYG editor to provide the experience they’re seeking. If they’re not afraid of the editing box they see on the webpage, they’re a lot more likely to actually use it.

The more I work inside the dynamic world of web content management systems, the more I wish I hadn’t put off the implementation for so long. It’s taken a year to get to this point, but we’re zoomin’ now!

This is an empty template for the old static page:

<!doctype html public “-//w3c//dtd html 4.0 transitional//en”>

<html>

<head>

<title>ATST: Page Title</title>

<!—#include virtual=“/templates/header.html” —>

<h1>Page Title</h1>

<!—#include virtual=“/templates/logotop.html” —>

Content here.

<!—#include virtual=“/templates/footer1.shtml” —>

Last modified: <!—#echo var=“LAST_MODIFIED” —>

<!—#include virtual=“/templates/footer2.shtml” —>