Let's talk a little about content management systems (CMS). Your library's CMS will be the heart of your new digital branch. Your Web team will take whatever CMS you pick and will design the digital branch on top of it. They will base all future decisions on and around the CMS. Anything they add later on will need to be based on the functionality, features, and expandability of this CMS. So it really behooves you to get this decision right very early on.

The CMS is the control center of your digital branch. It allows you to administer content within the branch: how it is organized, displayed, and accessed; who can access it; and how it can be accessed. According to one definition, a CMS is “a tool that enables a variety of (centralized) technical and (de-centralized) non technical staff to create, edit, manage and finally publish (in a number of formats) a variety of content (such as text, graphics, video, documents etc), whilst being constrained by a centralized set of rules, process and workflows that ensure coherent, validated electronic content.”¹

A CMS will make your library's Web life much easier. Most of your library's staff will be adding content to the digital branch, but they probably won't have advanced HTML or CSS skills, and they probably don't have a web-site editing software package like Dreamweaver installed on their work PCs. With a CMS installed, all those staff members need to add or edit content for their digital branch is a Web browser. In fact, adding content will be similar to creating an e-mail using a Web-based e-mail solution like Yahoo or Gmail. Most CMSs use automated, built-in templates. Once these templates are set, your staff has to worry only about content—the “look and feel” is already created.

Since a CMS is Web-based, it will be much easier for your techie staff to deploy. All they have to do is train library staff to use the new tool (which will be easy—it will be the “Go here, click this button, start typing, press Publish” type of training). Once you have a CMS in place, anyone who can type in a box and press a button will be able to add content to your digital branch.

Adding new content is easy and can be done through a Web-based form. This page will look very similar to e-mail or Microsoft Word. The user basically types in a box, then presses the Publish button. The CMS will have many of the normal features that you find in other boxes you type in—bold, italic, underlined text, a way to add a Web link, etc. Once content is published, if you need to go back and edit it some more, a CMS makes this easy as well.

A very important point for libraries—there's really no reason to spend lots of your library's money and purchase a CMS. Many of the popular CMSs used today, even by large corporations, are free, open source, well-supported and well-documented software, so no up-front costs are attached.

The functionality of different CMSs varies. If you are building a digital branch, these functions are essential:

• RSS—You will want your CMS to have RSS feeds built in.
• Articles or blog posts—Most likely, you will want a CMS that can post articles just like a blog does. In fact, multiple blogs with multiple RSS feeds can give you even more options for content. These can also act as stand-alone webpages.
• Comments—You'll probably want a CMS that can handle comments. Create comment boxes on the front end that match up with content on your site and have a way to moderate, edit, release, and delete comments on the back end. Even better is a “naughty word” blocker so you don't have to constantly search for those seven bad words your board or administrators really don't want to see on your digital branch.
• Ratings—It might be nice to rate each article, event, etc. A one- to five-star rating system does this nicely and is found on many a CMS.
• Categories—It is useful to be able to assign one or more categories to an article.
• An easy way to edit pages—You'll want this on the back end. You don't want to force nontechnical staff to learn advanced XHTML and CSS (though it's helpful if they DO know these things). Instead, it's much better to have them log in, click the New Post button, and start typing.
• Multiple logins at different levels—Nontechnical staff should be able to log in easily to their part of the website to post content, but not have access to back-end settings. The feature of different user accounts (e.g., user, editor, and administrator) is handy.

There are many CMSs to choose from. Here are a couple of the more popular ones, plus the one my library is using at the moment.

As you look through a large list of CMSs, you'll notice something—they're written for different types of servers. Some are written primarily to be installed and run on a Microsoft Windows–based server; others are written to be installed and run on a Linux-based server; and some work on both platforms. You now have a lot of options and an important choice to make.

One crucial consideration is your IT staff, or whatever IT resources you may have on your staff. Can they handle the CMS you choose? Will they be able to learn it? As you are picking a CMS for your website, think about these things:

• What does your data center look like? What are your servers? Are they primarily Windows-based servers? Will a different type of server fit into your maintenance and backup and storage plan?
• Are your IT system administrators able and willing to learn new things? Many libraries are set up with Microsoft products primarily on the back end, and the system administrators have little or no training in a Linux-based system. If you choose Linux, they will have to learn how to manage a different type of server.
• What different coding languages does your CMS use? Does your IT/Web staff know that language? If the CMS runs in PHP and stores things in a MySQL database, can your staff deal with that?

For the most part, the modern Web—even large sites like search engines and stores—runs on a mix of open source, JavaScript, and PHP. This generally means using a flavor of Linux-based servers is best. I suggest going with that, and, if necessary, training your technical staff to use and maintain a new type of server. Of course, like most aspects of building a digital branch, much depends on your circumstances and individual preferences.

When designing any website, it's best to start with the site's main page. Start by figuring out what content you need on the page and where you need that page to link. What services are important enough to be mentioned on that main page? Do you have a logo? Where should it be positioned on your page?

Next, you should get a piece of paper and start sketching ideas. It might be helpful to take a peek at other websites. Make sure to look at a few library websites that you respect, and see what they've displayed on their main page. But more important, get out your list of websites that your customers are using and examine those websites. Visit some universally visited websites, like Amazon, eBay, and CNN.com. Incorporate elements of those websites into your paper prototype.

Then start sharing your design ideas. If you have a Web committee tasked with redesigning your site, meet with them. Sketch design ideas together and share, then finalize the paper design by combining the best overall features and design ideas of each.

Once you have decided on your design, the next step is to do a mock-up that can reside on the Web. While the mock-up doesn't have to be fully functional, it should have some of the functions so you can get an idea of what it is like to click through the design. At this point, you're not really coding for functionality or using a CMS. Instead, you are making HTML representations of your paper sketches. Get this functioning at a very minimal level, then start showing it and gathering feedback.

You should seek feedback from people who are going to interact with the site. I'd start with administrators and managers, as they are the staff members whose approval will be so important to launching the site, and in most cases they get ultimate veto power. You want to make sure they are on board from the beginning. Make sure this group likes the design and the direction you're taking. Also check with staff, since they work directly with patrons. If you plan on doing usability testing, this is the time to do it!

During this process, expect a variety of comments. Don't take them all to heart, but rather listen for trends. For example, if one to three people say, “Those colors are ugly,” but others like the colors, let those comments slide. On the other hand, if you hear that comment from half of the people that you talk to, you may want to consider selecting new colors.

I'd also suggest getting some feedback from customers. Library managers need to like the new design, and front-line staff need to help patrons with the new site. Ultimately, however, your patrons are your most important group. They are your library's community and will be the digital branch's most important customers. Ask them if they like the design, what they would change about it, and what they are expecting from a digital branch.

Once you have a good amount of feedback, start winnowing it. If certain things keep popping out at you, fix those issues. Add any requests that make good sense or new thoughts that came from the feedback. Show the revised version of the website around one more time, and do the same process again. Once that's done, you can start building.

Time is first on this list for a reason. You have to set aside a lot of time to build a website. A simple blog can be built pretty easily—set up a free account, pick a name for it (the hardest part about blogging, besides the content creation), and choose a skin (or design) for your fledgling blog. Presto! You've built a blog.

A fully functioning library website is a different animal. A library website tends to be a fairly large and somewhat complex site that consists of many pages and a lot of content. There's the main page to design, but there will be other page templates to design and build, plus potentially thousands of individual pages that need to be copied over from the previous website to the new digital branch. Library websites are complicated and time-consuming to build.

It's important that you are realistic about the time it is going to take to build the site and the time that staff members will have to work on it. The day-to-day functions of the library need to continue while you are building your digital branch, and building can be a complex process. By using conservative estimates, you can avoid making promises that you can't deliver on quickly or giving out launch dates that need to be pushed back.

You will need to set some firm deadlines. No one ever builds the perfect website, but at some point, you have to release it, or go live with what you have. Remember, since this is a digital building, you can knock it down and start over, or add a room, relatively easily. It doesn't cost any actual money to do that unless you have hired a Web design firm to build your site, which is out of reach financially for many libraries.

Here's what Tom Mochal, President of TenStep, Inc. and columnist at TechRepublic.com, says about deadlines:

I'm convinced that a project team without a firm deadline will be unfocused and will ultimately take much longer to deliver than necessary. It sounds like you have a similar concern. So, when I see projects that are like this, I work with the project team to have them set a reasonable deadline, and then I hold them accountable for that date. This allows the team to work with purpose and focus. It's also a way of making sure that the projects don't continue indefinitely. Even if the client doesn't have a sense of urgency on when the project is completed, I want to make sure that the project team doesn't have this same attitude.⁷

In order to keep your project on track, you'll want to set deadlines, even if the library board or other governing body hasn't set one for you. Otherwise, the staff building the project will be unfocused, might tend towards perfectionism, and won't be able to give time to other important tasks and projects.

How do you set deadlines and manage time? Easy. Ask your Web-building staff how much time they will need, and then add some extra “wiggle room” time to that estimate. Here's what Merlin Mann of 43 Folders suggests:

In my days as a project manager (and in another life as a freelance designer), I got into a habit that has served me well to this day: get the best estimate of both job requirements and time-to-completion that you can find. Then add 20%. Then, when nobody is looking, add another 20%. Then pray.⁸

Of course, you have to consider the time of the people who will actually be building the site. You have basically two options here: use the Web staff you already have, or hire a freelance designer or Web design firm to build your site.

Obviously, we are all subject to financial constraints when it comes to IT staff. That being said, if you really want your digital branch to be an important part of your library, the best work will usually come from hiring a developer or dedicated staff member to build and maintain the site. If this is not possible, it is best to centralize these responsibilities as much as possible and keep them in the hands of a small number of staff members.

Once your site is built or redesigned, you will still need that Web staff onsite—there will always be a lot of work to be done. They will need to run analytics reports (and actually understand what those numbers mean). They'll need to fix things that go wrong. They need to train staff on how to post to the site and how to hack up a bit of HTML to make their posts better, and, of course, they will continue building new projects. Staff should be able to test the site, answer customer e-mails, help customers find information, listen to the hang-ups people are having with the site, and do usability testing. Once your site is “done” and has gone live, staff can have a sip or two of coffee and relax—for a week or so. Then they need to start planning the next release. You want to continually redesign, rather than doing it once every three years.

If you are hiring Web staff, make sure to hire people who know what they're doing! Yes, this sounds a bit obvious—of course you would hire someone who knows how to build a website for the webmaster job, right? Well, lots of libraries don't actually do this, believe it or not.

For instance, imagine a library hasn't hired a webmaster for nine or ten years. Now that person has moved on, and it's time to hire again. So what do some libraries do? They dust off that webmaster job description from 1998 and send it out again—not the best strategy when Web technology changes as fast as it does. Most likely, that job description mentions HTML and maybe (if you're lucky) CSS. It's old and outdated, and the only person who realizes that has left the building, so to speak!

So what can you do if you're in that situation, or one similar to it?

• If you ever have an IT staff member leave, ask the person who is moving on to update his or her job description before leaving, paying special attention to job requirements. This way, you'll at least get someone who has the skills to do what the previous person did.
• Ask another library to look over the job description. Someone recently had me look over their job description for an open Web staff position. What I described above pretty much held true. They had an outdated description that didn't include the skills they actually needed. With an update, they got applicants (they hadn't gotten any with the old job ad).
• Look at other job ads and the requirements they list. Don't look only at library job descriptions. Instead, go to places like the 37signals Job Board (see figure 12) or CrunchBoard Job Board and look at the job descriptions for Web developer positions. You can find helpful wording and job titles from those job sites.
• Talk to other people in your community who have hired IT staff. If you have friends or know of local businesses that hired people, talk to them. They can help you understand the process and might even be able to give you some contacts.

37Signals Job Board

http://jobs.37signals.com/jobs

CrunchBoard Job Board

www.crunchboard.com/jobs