Again, this not a technical issue. It's a content strategy issue.

Believe me, I was where you were. I was using all kinds of javascript and
CSS hacks to try to prevent people from getting creative with color. I was
getting to the point of setting up Capybara tests to run against the guides
to alert me to abusive uses of bold and italics.

The folks creating guides are content people, not web people. Take the web
out of it. Focus on the content. Pick a couple heuristics to educate them on
(we picked 7 +/- 2, above the fold/below the fold, and F-shaped reading
patterns). Above all, show them statistics. And not the built-in LibGuides
stats, either.

New vs. returning. Average time on page. Pageviews over the course of a
year. Very, very, very quickly our librarians realized what content is
important, what content is superfluous, and that the time the spend
carefully manicuring and maintaining their guides would (and could) be
better spent elsewhere.

-Sean

On 8/12/13 9:35 AM, "Joshua Welker" <[log in to unmask]> wrote:

> I just have to say I have been thinking the exact same thing about LibGuides
> for the two years I've been using it. I feel vindicated knowing others feel
> the same way.
> 
> At UCMO, we will be migrating to Drupal in the next several months, and I am
> hoping very much that I can convince people to use less LibGuides.
> 
> LibGuides is great in its ease of use, but fails on just about every design
> principle I can think of. There have been several studies on "tab blindness"
> in LibGuides, and don't get me started on the sub-tab links that are hiding
> and require the user to mouse over a tab to even see what is there. I've
> tried telling people so many times to have just a few tabs and always to use
> a table of contents for the main page, but they rarely do. And it becomes
> just about impossible to have a consistent look and feel across your website
> when LibGuides allows guide creators to modify every element on the page as
> they see fit. People will do crazy things like putting page content in a
> sidebar element, something you'd never ever ever see on any website on the
> Internet. I tried to enforce uniform colors and column sizes across all the
> guides, but I was told to let it go because my coworkers wanted to be able
> to decide those things on a guide-by-guide basis.
> 
> I've worked at two institutions that use LibGuides, and what inevitably
> happens is that librarians create one Uber Guide for entire subject areas
> (biology, religion, etc) and then create sub-pages for all the dozens of
> specific disciplines within those subject areas. And then, assuming the user
> somehow manages to find these pages, they are typically not much more than a
> list of links that could have easily been included on the main library
> website.
> 
> Okay, sorry for the rant. It has been building up for several years and
> never had a chance to voice out.
> 
> Josh Welker
> Information Technology Librarian
> James C. Kirkpatrick Library
> University of Central Missouri
> Warrensburg, MO 64093
> JCKL 2260
> 660.543.8022
> 
> -----Original Message-----
> From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of
> Robert Sebek
> Sent: Sunday, August 11, 2013 11:21 AM
> To: [log in to unmask]
> Subject: Re: [CODE4LIB] LibGuides: I don't get it
> 
> 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 (http://www.lib.vt.edu/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
> (http://www.lib.vt.edu/)