Where the Bucks Stop
Leo Robert Klein maps how to staff to meet expectations and decision-making for library web sites.
Leo Robert Klein (netConnect) -- netConnect, 4/15/2001
How library sites get built must seem very strange to people unfamiliar with the nonprofit or academic world. First there's the more collegial way of making decisions: the various departments, factions, and personalities, each with their agenda. Agreement is more 'arrived at' than 'handed down.' Then there's the distributed nature of resource production itself: staff librarians in various departments are called upon not only to contribute material but on occasion to turn it into HTML, to select and process the images, even to determine navigation and layout--all activities for which whole job categories are carved out in a larger corporate setting. Someone looking in from the private sector might wonder how our enterprise manages to get off the ground. (And we, in our weaker moments, might wonder the same.)
But even in the world of strained budgets and understaffing in which we live, some order can be brought to the process of web site creation. Underlying every project is an organizational chart, whether we want to acknowledge it or not. Often real-world limitations mean we cannot change our current messy diagram of circular reporting, dotted-line relationships, and cross-departmental teams into a hierarchical pyramid--and to be honest, most of us do not want to work in that kind of place. However, it makes sense to go over the expectations and responsibilities everyone has for the 'community' web site. In this way we can avoid a ton of misunderstandings and disappointments.
Web manager
This is the person directly responsible for running the library's web operations. Whether this is a full-time position depends on the size of the institution, perceived need, and available resources. Typically, the web manager works in conjunction with a committee that passes on things like overall web policy and the general look and feel of the site. It falls on the web manager to deal with the day-to-day operation of the site. Most web managers are something of a unique hybrid, combining technological expertise with an editor's feel for content. At least they should have both skills, as it is the rare web manager who doesn't have a finger in both pots.
On the technical side, the web manager needs to keep abreast of new developments not simply in the technology but in our understanding of how web-based media ought to be delivered--both fairly rapidly evolving areas. The web manager needs to give consideration to how these new developments can enhance the library's online presence, even borrowing from the private sector when those models seem appropriate for library use.
That's the fun stuff. It's also part of the web manager's duty to look at a proposed project and imagine all the things that could possibly go wrong--in other words, to go over the nightmare scenarios. This may not sound like one of the most pleasant tasks in the world, but basically it's no different from what professionals do in the healthcare industry, on building boards, and in government regulatory agencies. Health is one thing, Mark Twain wrote in his autobiography, but illness is many. It's up to the web manager then to look at a proposal and work out the possible difficulties. Generally, there will be quite a few.
Once something is served up to the online user, it's 'anything goes.' Of course the environment isn't completely unpredictable, but there is a wide margin of possible systems, monitors, personal preferences, settings, and the like that have to be taken into account. So much for the limitations on the outside. In house, no matter how extravagant the support is from administration, there are also going to be limits in the form of time and expertise. Everyone wants a database, for example, and yet databases don't grow on trees. The web manager will be able to run with a project only as far as its resources allow--which is rarely as far as people's imaginations.
Getting a project off the ground and on the road to completion then means making a compromise with what is feasible, and it is the web manager's lot--being the last one on the chain prior to implementation--to administer what must seem like a dose of bad news to people heretofore happily unfamiliar with web constraints. In fact, by knowing the pitfalls and explaining them clearly to others, the web manager is hopefully ensuring that a given project will actually arrive at completion and that it will be enjoyed by the widest possible audience.
Administration
A library's web site is the public face of the institution, setting the tone for what the institution is for those inside and outside of the building. In addition, the library's web site is how many of its services--including some of the pricier ones like databases--are delivered. For these two reasons, administration is likely to be highly interested in how things on the library's web site are 'progressing.'
Administration's role is to determine what level of priority the library's web site, and digitization efforts in general, have in the overall scheme. Once this determination is made, it's up to administration to flesh out the commitment through budgets and personnel. No one's resources are infinite, but in preaching the gospel of digitization, administration should make sure that library staff involved in the digitization effort have the equipment they need to do their tasks. This doesn't mean PCs that compare well with what everyone else has in the office but rather that everyone working on the web site has PCs that are a little closer to industrial strength. Then again, the significant difference here is not so much in costs as in attitude, particularly where systems support staff are used to a more leisurely and generalized upgrade path. Administration can play a helpful role getting people to 'shake a leg.' It also helps, in this respect: if the upgrade path for staff and public terminals is not too long--particularly in those areas that don't require a renewed outlay of cash, e.g., keeping plug-ins and other 'free' software current.
Administration's greatest contribution possibly is in recognizing the work of all those involved with the development and maintenance of the library's web site. This begins with professional staff supplying material (more on this later) and moves up to the individual with overall direction of the site. It's up to administration, given the means and nature of the institution, to define the professional caliber of the person who's running the site. Institutions that have made this a professional position (e.g., 'web librarian,' 'digital librarian') are really leading the way since the manner in which library material is communicated to the public online is as critical and as specialized an activity as any more traditional subject category. Happy is the administrator who realizes this and is in a position to offer adequate recognition.
Professional staff
These are the people supplying material for the site. Without them, we're like a newspaper without reporters. Since these people are supplying whatever substance the site is likely to have, their participation is absolutely crucial. It is part of the responsibility of the web manager and administration to drum up enthusiasm for this very activity. Projects once completed ought to be rolled out with all the fanfare of a Nobel prize, just so the people responsible for the work feel that they've actually accomplished something. Putting something online is nothing new, but earning 'Brownie Points' for it is still all too rare. Too often, supplying content and keeping it up-to-date is seen by staff and administration alike as just another tangential add-on to an already too-busy schedule.
Firing up people is only half of the story, however; the other half is channeling that energy into areas where their expertise can play a positive role. Participation ought not to be seen as an opportunity to rethink the entire web site now that staff have a chance to 'show their stuff.' Going where no one has gone before is fine for Federation starships, but perhaps the most responsible thing a person can do before embarking on a project is to have a good look at how things stand currently on the library's web site.
Most sites already have an agreed-upon style. There are colors and fonts that will be preferred. Headers and footers are generally sitewide, and it's important to design one's page with these in mind. Equally as important, perhaps on a more profound level, is considering how the new material is going to fit in with the old--particularly with the existing information structure of the site. The emphasis should be on integration, not addition or duplication. Integration reinforces the current structure of the site whereas addition--'yet another category'--and duplication--'same information, here, there, and everywhere'--tends to dilute the structure and confuse the user.
Often new developers are concerned that users are going to bypass their creations. The concern is understandable since the developers may have devoted a considerable amount of time to creating the resource. To prevent this, they want the piece to get top billing--or, in other words, to get as close to the top level of navigation and hence to the homepage as possible. Clearly this cannot always be accommodated, particularly when it crowds out other more critical resources. One remedy is a standard way of introducing new additions to the web site; another is an understanding by all parties of the web site's priorities. After all, the entire library staff don't suddenly rush to the door every time someone walks in. With even less space on the library's homepage, serious choices have to be made and adhered to if only to avoid confusing, or scaring away, potential visitors.
The user
Those responsible for site development--be it the web manager or a team--have to learn to trust users more and to resist the urge to clobber them over the head with the message of the moment. It doesn't take too many flashing banners or pop-ups to anesthetize a user totally to any further messages no matter how restrained the delivery becomes. What's more, the bad practices of others come home to roost with us since an individual wary of the abuse of such attention-getting devices on other sites isn't going to look fondly upon their presence on ours. In any case, there's always an advantage to not shouting at our users or appearing too heavy-handed.
A common mistake, for example, is to think of every possible contingency and then to include them all--just to 'play it safe.' How, the thinking goes, can anyone possibly use a service--say, one in which a form is required--without thoroughly understanding all 47 steps involved in the process? Then, having survived this trial by policy, the user is next expected to run a gauntlet of 21 or so questions, all for something no more complex than registering for a library workshop or trying to find someone to answer a reference question.
There's always going to be some utterly compelling reason to add yet another layer to the process, yet another question to the form. To counteract this, web managers should ask themselves if the additional layer or question truly is essential to the purpose at hand. If not, then it's best to do without it. The simple truth is, users will make mistakes. It is better to develop a system that takes this into account--a system that's fault-tolerant but ultimately friendly and inviting--than to swamp users with every instruction and question in the world, which by their very number may deter site usage. If managers stiffen their resolve, they will develop resources that are far more welcoming and easy to use.
Leo Robert Klein (leo_klein@baruch.cuny.edu), MLS, is Web Coordinator and Digital Resources Developer, William and Anita Newman Library, Baruch College, CUNY. He received a master's degree from the Interactive Telecommunications Program at New York University
