I've found that librarians gravitate towards tools like LibGuides and
WordPress because they want to use what they've seen other libraries using,
putting me in a strange position when try to explain that we (with more
tech resources) can actually do better.

Several times I've had the experience of proposing something like: we could
have a blog built right into our Drupal website with the same theme, even
incorporate it into our homepage! "But that doesn't look like a blog."
After some digging, I found that these particular librarians/administrators
thought what a blog looked like was something not integrated with the rest
of the website, at a separate URL, using an off the shelf WordPress theme
that didn't match anything else. Like they couldn't tell the difference
between a compromise and a feature! Sigh.

Same thing with LibGuides--someone saw them and got gung-ho to subscribe
right away. I offered, "We have some basic subject guides in Drupal, but we
never embellished the content type because no one was creating them." But
they thought a subject guide *should* have a too-small font, lots of RSS
feeds for not-necessarily-important content, and of course a dozen tabs
across the top. (And that having those features available would magically
inspire librarians to spend lots of time creating and maintaining subject
guides, despite the fact that no one did before.)

I'm with Robert--why spend money *encouraging* a "Big List o' Links" style
of library service?

And in case anyone missed it when it was going around Twitter a few days
ago: My Content Strategy/IA

On Sun, Aug 11, 2013 at 9:21 AM, Robert Sebek <[log in to unmask]> wrote:

> On Sun, Aug 11, 2013 at 9:54 AM, Heather Rayl <[log in to unmask]> wrote:
> > I have to say that I loathe LibGuides. My library makes extensive use of
> > them, too. Need a web solution? The first thing out of someone's mouth is
> > "Let's put it in a LibGuide!"
> >
> > Shudder
> >
> > This fall, I'll be moving our main site over to Drupal, and I'm hoping
> that
> > eventually I can convince people to re-invent their LibGuides there. I
> can
> > use the "saving money" card, and the "content silos are bad" card and
> > *maybe* I will be successful.
> >
> > Anyone fought this particular battle before?
> >
> > ~heather
> >
> > I'm fighting that battle right now. We have an excellent CMS into which I
> have set up all our database URLs, descriptions, etc.Anytime we need to
> refer to a database on a page, we use one of those entries. That database
> just changed platforms? No problem. I change the URL in one place and
> everything automatically updates (hooray CMSs!).
> All of our subject guides ( are in
> the CMS using the exact same database entries. I converted from our
> failing, home-grown system into the CMS and then gave training on how to
> maintain from there (remove an entry, add an entry, create a parallel
> course guide)--using the same skills as maintaining any other web page that
> librarian is responsible for. But apparently that's too hard.
> So we have a trial of LibGuides. NO ONE here has created a guide from
> scratch yet,  but they all say this is going to be easy. No one will admit
> that someone will have to recreate all those database entries (literally
> hundreds) and then maintain those entries. When presented with this,
> several librarians said--oh that won't be necessary, we'll just create
> individual entries as needed on individual guides. WHAT?!
> If implemented, we'll have hundreds and hundreds of entries, any of which
> could be out of date and nonfunctional, with no easy way to find and fix,
> other than waiting for patrons to complain that the link doesn't work. Ugh.
> All for several thousand dollar a year (as opposed for free in the CMS).
> And yes, those librarians' favorite example libguides have a dozen tabs
> with hundreds of links on each tab. Overwhelm the patron with links--who
> cares! Just let me recreate the Yahoo Directory I so miss with every
> possible resource I can find online. Half those links don't work next
> semester? Doesn't matter, as no one will ever maintain that page again (and
> no patron will use it, since they will just Google these resources anyway).
> --
> Robert Sebek
> Webmaster, Virginia Tech Libraries
> (