[Web4lib] Design Considerations for Library Website

[Cary Gordon]

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

On Fri, Jul 8, 2011 at 7:40 AM, Michael Schofield <mschofield at neflin.org> wrote:
> Morning everyone,
>
> I am collaborating with a couple of other bloggers on a series about
> designing library websites specifically, virtualizing services, etc. I
> thought it wouldn't be a bad idea to poll the hive of librarians/designers
> who've been designing in this market for a long time now. So,
>
> What design considerations do you think are important to make when building
> sites specifically geared for patrons?
>
> Other things I'm interested in!:
> What have you tried - and what failed?
> Why choose one CMS over the other?
>
> If you give me your name and a site we'll make sure to plug you on Hack Lib
> School, The Geek Library (for what it's worth lol), and wherever else the
> series is posted.
>
> Thanks!
>
> Michael Schofield | mschofield at neflin.org
> www.michael-schofield.com | www.theGeekLibrary.com [new]
>
> _______________________________________________
> Web4lib mailing list
> Web4lib at webjunction.org
> http://lists.webjunction.org/web4lib/
>
>



-- 
Cary Gordon
The Cherry Hill Company
http://chillco.com