In a response to a question posted to
Web4lib on Library Web Site design and management by Michael Schofield, Cary Gordon from
The Cherry Hill Company offered the following observations from his experiences. Reproduced with permission (Thanks Cary!).
I have been building websites and web based applications for libraries since 1994 (yipes), and I have some opinions, none of which should shock anyone. Here are a few:
1) Most library home pages are much too dense. I have worked on a few sites that started as elegant designs, then became unusable as more committees got involved.
1a) Lesson from 1: Committees are fine, but it helps to have a single person at the top who will guard the flame.
2) Landing pages should address a specific set of user needs. If you have users with conflicting or disparate needs, create separate landing pages for them.
3) There is some confusion between usability and user experience (UX).
You can have a fabulously usability standard compliant site and still deliver a terrible user experience.
4) Build your site for the users you have, not the user you would build, if you could. You know what they want. Really, you do.
4a) This is not to say that you shouldn't highlight great resources at your library, just that you should not let them get in the way of someone trying to find out when you are open.
5) Building a site that is friendlier to different kinds of devices than you think you need is probably a really good idea.
In an ideal world, we would be able to figure out what we need from logs and analytics. Unfortunately, these tools can't usually tell us about what we don't have. Likewise, if you don't have a mobile friendly site, the user agent count isn't going to reflect the amount of traffic your site would get, were it friendlier to those clients.
I think that it is a good idea, albeit sometimes disappointing, to limit the scope of a new site to what you can maintain. To me, it is better to not have a feature than to have a feature that is disused or out of date. It doesn't bode well to go to an event calendar on a library website and see that the last entry was two years ago.
I think that these items can help:
1) Commit a specific amount of dedicated staff time to maintaining your website.
2) If possible, use a content management system that is set up in such a way that contributors and editors can concentrate on content rather than code. In other words, Ruby on Rails, which is great, is probably not a viable choice unless you have strong RoR resources on staff.
3) Unless you have staff with nothing else to do, if you do not have dedicated IT staff, have your website hosted by a reliable company.
There are reliable hosting companies starting at about $10/mo, and fully managed hosting available from about $75/mo.
4) If you use a CMS or other software, invest staff time, and money, if necessary, in training, and make sure that the training is appropriate to what you are trying to accomplish.
5) Don't lock in to any more dedicated workflow than you really need or can support in practice.
I started coding sites by hand, moved to external content management systems (like Fusion), server side includes, bespoke CMS in ColdFusion and Java, and eventually to Drupal. I think that Drupal is a great solution, because it is built by its community and the strong peer support from its library user community.
Drupal is not, of course, the only solution, there being over 1,000 competing systems. As I asserted earlier, I think that most libraries should use a content management system. That would include Drupal, WordPress, SilverStripe and many others. I personally prefer free and open-source solutions to commercial products and products that have broad adoption to those that get little play. I like to look at the ratio of sales staff to programmers and support. Of course by those standards, the big ILS products look scary.
Virtual servers are an interesting topic, but I think that it is more important to broach the question of whether you plan to do your own system administration or not. We run our own data center in downtown Los Angeles (with a small branch in San Francisco), and will probably continue to do so for a while, but it seems pretty clear that eventually, it will be more economical to move this to "the cloud."
For us, this will really be a bottom line focused change, since we will still need a system administrator on staff, and we only spend a tiny amount of time on-site, with most of that devoted to equipment upgrades and replacement that we wouldn't need in the cloud.
Thanks,
Cary
