Progressive Enhancement

I start every webpage with semantic HTML. No CSS, no JavaScript, no thought to presentation. I just make it well-structured in HTML. After I have a semantic page, I go back through and write separate CSS. Here I’ll add classes and wrap content in divs to help with presentation, but I never make a change to the structure that doesn’t fit with the semantic nature of the document. After I’m done with the presentation, I go back through and add any interaction JavaScript. I never put JavaScript inline in the HTML document. I include it all in a separate file, so that JavaScript is not required to read the content or interact with the forms. After all, I want each of these layers, semantics, presentation, and interaction, to be separate. As the user’s device supports more features, I progressively enhance the experience.

Example of the Big Stuff: Getting Animated

When I met with our Scholarly Communications team to tart up our institutional repository, it became clear that the IR’s homepage would primarily be a marketing tool to entice faculty and departments to get on board with Open Access². I suggested a slideshow of images to highlight faculty who are already depositing their work in the IR. Not only would this serve as a great and highly visible marketing tool for the Scholarly Communications, but it would help to break up a text-heavy website that serves as a repository for text-heavy articles.

For the slideshow, I chose jQuery, a powerful JavaScript library, as well as Mat Marquis’ responsive carousel. The script works by taking an unordered list of images and showing one at a time, animating the transitions between images. As you can see, the markup is nice and semantic.

<ul>
    <li><img src="img/image1.jpg" alt="Professor Smith presenting at Awesome Conference 2011" /></li>
    <li><img src="img/image2.jpg" alt="Students being studious" /></li>
    <li><img src="img/image3.jpg" alt="Professor Jones with her nose buried in a book" /></li>
</ul>

There is a downside to this, though. If JavaScript isn’t available, this is what you get:

The unordered list is displayed as just that: a list of images. This creates an incongruous pile-up of images that confuses users. So how can we address this consequence of using JavaScript? Is it by running in fear? No. The answer is JavaScript³.

Since the slideshow will only work when JavaScript is available, why not make the unordered list available only when JavaScript is available? Using jQuery, this is a piece of cake. Instead of hard-coding the list into our homepage, we’ll add an appropriate element for non-JavaScript browsers and then replace it with JavaScript if we can.

I decided to use the first image in our list as the “non-JavaScript” fallback, since semantically a slideshow is just one image at a time and visually the design would be unchanged. This is the markup:

<div id="slideshow-image"><img src="img/image1.jpg" alt="Professor Smith presenting at Awesome Conference 2011" /></div>

<p>Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat...</p>

This is nice, semantic markup, and using CSS, we’ll make it look sharp. But when JavaScript is available, we want to change the markup to work with the slideshow. Using jQuery, we simply need to include the following code in our script:

$(document).ready(function() {
    $("#slideshow-image").html('
        <ul class="slidewrap">
            <li class="slide"><img src="img/image1.jpg" alt="Professor Smith presenting at Awesome Conference 2011" /></li>
            <li class="slide"><img src="img/image2.jpg" alt="Students being studious" /></li>
            <li class="slide"><img src="img/image3.jpg" alt="Professor Jones with her nose buried in a book" /></li>
        </ul>');
});

Now the content of the slideshow-image div will be replaced with the HTML above⁴. Add in the code to animate the slideshow, and we have a seamless enhancement for users who have JavaScript-enabled browsers. It’s a win on the semantic level, a win on the presentation level, and a win on the interaction level. Everyone gets a version of the page most appropriate to their browser’s abilities. It’s like the Web version of a Montessori school.

The “Small” Stuff: Accessibility

This method of layering JavaScript over semantic HTML is used throughout our site. We use it for high-impact things like slideshows and our drastically simplified link resolver, but we also use it for small things that make accessability a priority while not shackling great presentation. One example of the latter is our Summon search bar, present at the top of every library webpage.

To be semantically correct and accessible, this input field needs a label, but visually, we want to use placeholder text to replicate the label. So we used progressive enhancement to solve these seemingly conflicting needs. I see four scenarios I needed to account for:

1. Browser with native placeholder and JavaScript support
2. Browser with JavaScript support but no placeholder support
3. Browser with neither JavaScript nor placeholder support
4. Browser with placeholder support but no JavaScript support

First, we started with semantic HTML:

<div id="summon-search-box">
    <label for="search" id="summon-label">Find Books, Articles, and more</label><br />
    <input name="search" placeholder="Find Books, Articles, and more" type="text" />
</div>

Here is what we need to do in each scenario:

1. Hide the label, since placeholder support will show the text the way I want it.
2. Hide the label and use JavaScript to patch placeholder support.
3. Nothing. The label will be visible and will remain semantic.

In the last scenario, there isn’t much we can do. We’ll have both a label and a placeholder visible. In our case, this rarely ever happens, so I didn’t worry about it. In any case, the form is still functional, there is just label redundancy. I decided I could live with it. So the presentation and interaction work needed to focus on the first two scenarios.

In both of the scenarios when JavaScript is available, we need to hide the label. So I started with this jQuery:

$("#summon-search-box").find("label").hide();

That takes care of the first scenario. For the second scenario, I detected placeholder support with the JavaScript library Modernizr. If placeholder was not supported, I used a script to look for placeholder text and swap it out to the value until the input is focused on. This duplicates the functionality of the native placeholder text. The code I used was written by Nico Hagenburger, and it works great. The full code is below:

if(!Modernizr.input.placeholder){ 

    $('[placeholder]').focus(function() {
      var input = $(this);
      if (input.val() == input.attr('placeholder')) {
        input.val('');
        input.removeClass('placeholder');
      }
    }).blur(function() {
      var input = $(this);
      if (input.val() == '' || input.val() == input.attr('placeholder')) {
        input.addClass('placeholder');
        input.val(input.attr('placeholder'));
      }
    }).blur();
    $('[placeholder]').parents('form').submit(function() {
      $(this).find('[placeholder]').each(function() {
        var input = $(this);
        if (input.val() == input.attr('placeholder')) {
          input.val('');
        }
      })
    });
}   

So we can give our users engaging, rich experiences on the Web without breaking our sites for people with less-capable browsers (including many mobile phones). We just have to get over that irrational fear.

1. Summon, I’m looking at you. ↩
2. Most of our IR traffic comes from Google directly to the PDF stored in the repository. Of the rest, I suspect a significant portion are “vanity searches,” with GVSU faculty searching for either their own work or for the work of colleagues. ↩
3. Sadly, the vendor was too afraid of JavaScript to let me use any of the code I wrote, so were stuck with a crummy, ugly slideshow that doesn’t have a semantic HTML fallback for non-JavaScript users. (I’m not sure how that is better, but after 4 months of arguing with them, I gave up. You pick your battles. ↩
4. I know jQuery has replaceWith, which would allow me to eliminate the div, have the id on the img tag, and then just swap out the HTML, but support for replaceWith is spotty in IE7 and below. And we’re in academia, where IE7 sometimes seems like the cutting edge. Oi vey. ↩

1. Do one test every month.
2. Focus on what users *do*, not what we’d like them to do.
3. No more than 5 questions for a 30 minute test.
4. Test no more than 3 students or faculty a month.
5. Invite everyone from the library to observe. EVERYONE.

I can tell you from experience that getting librarians, front-line staff, and administrative staff all in a room together will get you better feedback than a room with only librarians or IT staff. I also guarantee you’ll get buy-in on making changes from all levels. First, you’re letting everyone see what is wrong with the site by showing actual users interacting with it. It’s pretty hard to ignore problems when they are encountered in actual use. Second, you’re letting everyone participate in the discussion. Not only does this get you better feedback, but it also means employees across all levels of your organization will appreciate getting a chance to contribute to something as visible as the website².

First, let me say that you can learn everything you need to know about usability testing from Steve Krug’s book Rocket Surgery Made Easy. We’ve adapted a few things to accomodate the special needs of a University library, but those might not be appropriate for your situation.

Setting up the test

The test is simple. We set up two spaces: a space for the test and a space for observation. I use my office for the test, setting up a monitor, a keyboard, a mouse, and a USB microphone hooked up to my laptop. Upstairs in the conference room I set up the observation room. For that I use my student’s laptop, hooked up to the room’s projector and sound system. You want to make sure that the observers can see the user’s screen and hear what is being said. That’s it for setup: I bet you already have all that stuff in your office.

For the first few tests, I also ordered food for the observation room, as a way to bribe staff into coming. Once I got a good turnout, however, everyone realized the importance of the tests and comes whether or not there is food.

Since we use Macs, we run Apple’s built-in AIM chat client iChat on both machines. iChat has a screen sharing feature that allows us to share the screen and audio from my office up to the conference room. It’s built-in and easy to use, and it doesn’t cost anything. If you have PCs, Skype has a similar feature.

That’s it for gear? Surely there is something fancier we can do? Getting fancy with your gear is just a distraction from getting the work done. Once you’ve got a few tests under your belt, then see if you feel like you need to invest in something better. After all, the goal here is to make your website better, not to do usability tests. Usability tests are just the vehicle to get you to a better site. If you want to get in shape, do you go running or do you buy newer, fancier running shoes? Which is going to help you trim your waistline?

What happens during the test

While I walk the user back to my office, I run through the basics of the test. Even though we’ve asked them to look over the consent form, they never do. I want them to know that I’m planning on recording them³ and that other people can hear our conversation before they are committed. No one has ever backed out, but they appreciate the warning before I spring it on them with a live microphone. I then read from a script all the details of the test. Once I’m done, I ask the user to sign a consent form that allows me to record the session.

I then ask a few questions about the user’s major, interests, and internet use, mostly as a warm up. I also want to find out if he or she has had any library instruction in their classes, although sometimes I wait to bring this up until we work through tasks.

Now we get to the heart of the test. I have 5 tasks that I have written up as scenarios that I read aloud to the user. I ask him or her to follow the instructions in the scenario, and to talk aloud about the choices he or she makes on the site. This is where you’ll learn the most about how well your site is succeeding.

Here’s an example: I wanted to see how users found articles with incomplete citation information, so I wanted them to find a newspaper article by Lawrence Lessig about Google and copyright. That’s the task. To make it into a scenario, I provided some context:

You meet with your Computer Science professor about an upcoming paper on intellectual property and the Web. She mentions an article by the lawyer Lawrence Lessig about Google and Copyright published in a newspaper, but she can't remember the paper or when it was published. Find this article.

Notice that I don’t have any tasks asking users to find our policies pages, or to learn more about a particular database. That’s because users don’t actually do these things; librarians do them. And, as I’ve said before, the website is for users, not librarians. (See also: website tenet #2.)

When all the tasks are over, I ask the observation room for follow-up questions. I then give the user a thank-you gift (in our case, t-shirts) and get ready for the next test. One test takes about 30 minutes.

Once all the tests are completed, I join the observation room and we spend an hour hammering out what we saw, what was a problem, and how we are going to address it. I try to limit the actual to-do list to 3-4 items, to make sure we can get them all done by the next test. There is no report other than an all-staff email that breaks down the tasks we’re going to work on over the next month, and no follow-up meetings, except for the next test.

We routinely have 12-18 people in our observation room, and almost universal buy-in on changes made to the website. In the past six months alone our website has transformed, from a typical library link farm to a usabile, simplified search engine our faculty and students seem to enjoy using. Below you can see the transition we’ve made in successive iterations, all as a result of usability tests.

We’re not done. We keep testing and making changes to the site, and will keep doing so. It is the single most important thing we do to make our library experience better for our users, since 100% of our patrons come through the website while only 50-60% come through the front door. It’s easy to do and only takes a little bit of time to yield incredible insights. So what are you waiting for?

Resources

• IRB test protocol PDF
• Consent Form PDF
• Test Script PDF
• Sample Packet for Observation Room, with scenarios PDF

1. Some call this the “real world.” ↩
2. Always make sure to give credit where credit is due. When someone else comes up with an idea, remember to always attribute it to them. You’ll do enough awesome things in your job, there is no sense stealing other people’s good ideas. Who knows, they might bake you cookies! ↩
3. You don’t need to record the sessions, but i find it useful to go back when I’m working on improvements to the site and watch exactly how the users had problems. Plus, we already had a license for Camtasia so it wasn’t an additional expense. ↩

We don’t have a huge budget for testing; our direct costs run about $30-40 a month. We don’t have a huge Web team; it’s just me and one 10-hour a week student. We don’t have a dedicated room for running the test or for doing observation; instead we use my office and a conference room. We don’t have a lot of technology dedicated to the test; we use my laptop and a decommissioned MacBook from 2008, along with a USB microphone. We just know that usability testing and the constant, iterative improvements it helps us make to our website are important, so we make it work.

I was fortunate when I arrived at GVSU last year, because the staff already knew that they needed someone to perform regular usability tests on the website. In normal universities, that means once a year the Web team dusts off some really expensive software ¹ and takes the storage boxes out of the usability testing lab, and sets up a big, 3-day event with a lot of statistics-collecting and silly question writing and whatnot. Nothing on the website ever gets changed because of these tests, but someone will probably wrangle an article full of charts and graphs out it, and maybe a few conference presentations where they fly across the country to read a bullet list out loud to a room of over-caffeinated librarians. The reason university libraries run their usability tests this way is because the website is made for the librarians, so why wouldn’t the usability tests benefit the librarians as well?

I have a mantra that I repeat in meetings and presentations. “The website is not for librarians.” Say it with me. If you’re a librarian (as I am) look in a mirror and repeat after me:

“The website is not for you.”

The website is for our users. Our students. Our faculty. And yes, our staff. But mostly for our students and faculty. Look at your average university website and see what sorts of things you can do on the site. You can probably read an FAQ with 300 entries, see folders full of policies, choose from a number of non-user friendly research tools (Database A-Z lists, Federated search engines, library catalogs, etc.)². That’ s because all of this stuff is what we librarians want, and what we like to do. We love writing policies. You know who never looks at policies? Our users³. We like looking at Database titles. We know, for instance, that you’ll find different things in a Knovel database than in Lexis Nexis. But you know who doesn’t know that, and frankly, shouldn’t have to care? Our users. They hate Database A-Z lists. Don’t believe me? Try asking one of them, or better yet, have them use one in a usability test. I won’t even say “I told you so.”

Here’s what our users do on our websites: find stuff. That’s it. And when I say “stuff,” I don’t mean policies, old assessment reports, strategic plans, and mission statements⁴. I mean articles. I mean books. I mean sources that will help them with research. They want to find that stuff and they don’t understand why it’s so hard. If they want a book, we tell them they need to use the catalog. If they want to find an article, they need to know the best subject-specific database (and all of its idiosyncrasies). Looking for help with your research? You need to know that Subject Guides or Libguides is the right place for you. This is ridiculous. Users have enough going on in their lives, they shouldn’t have to know all of this library jargon. They want to have one big fat search box that they can find stuff in, like Google. How do I know this? Do I have any statistics or fancy reports to back this up? No, but every month I sit down with actual users of our website to see how they find stuff and to ask them what they want. And I can tell you, they’re not itching for more policies pages.

This frustration brought GVSU to Summon. Summon is a web-scale discovery service from Serials Solutions. It’s not perfect, by a long shot. But it’s a start. And one of the first things I set out to do when I got here was to see how our users were using it. We’d already spent a good deal of time looking at usage statistics and comparing and contrasting things. Statistics can tell you a lot, but they can’t give you the context of why or even how someone uses something. The only way to find out how and why someone is using your website is to sit down next to them and watch them. Ask some questions. And then determine what got in their way and try to fix it. That’s it. By shedding the usual statistics-and-report dance, we keep the tests focused on what really matters: improving the website.

Google is great at improving its site to be better for users. It has to. One of the most powerful tweaks they’ve made in the past few years shows you results from Web, images, shopping, and places all from a single search. Summon does show results from databases, our catalog, digital collections, and LibGuides all on one screen, but it does so poorly. Based on watching our users interact with Summon during our usability tests we’re working on improving the search results screen so that users don’t need to know which tool is appropriate before they search. A few places have already done this to good effect. The University of Michigan does this with their search tool Deep Blue, although they do not use Summon, and do not search articles. (They have written a lot about usability testing on their Deep Blue, though.) North Carolina State University has one of the cleanest search results screens, pulling articles from Summon, books from the catalog, hits from the website, as well as database and journal recommendations.

This kind of change is not just something that we’ve heard our users say they want. We could scrap usability tests and do surveys and get that kind of information. Instead, this is something we see is needed because we watch our users trying to use our site like this now, even though the capability isn’t there yet. We’d never know that if we didn’t watch a few people use our site every few weeks and then try to fix their problems for the next time. It’s another channel we’ve opened in a dialogue with our users about how we can help them be awesome at their work. Running regular tests reminds me that the library website isn’t an end in itself, another trap libraries fall into. (Who goes and searches library websites for fun?) The library website is a just tool that should get out of the user’s way and help him or her do her job.

1. I’m looking at you, Morae. ↩
2. If your library website is like most you can probably also get to any page on the website right from the home page. Libraries love links so much that most of them look like spam link farms, designed to trick Google. Every other successful website on the planet gave that up in the late ’90s, but not libraries. We librarians like to see a big list of resources because it makes us seem more relevant. “Look at all this good stuff we have! We’re not just for novels anymore! We won’t shush you, either!” ↩
3. I have a theory that policies exist on the website so that public service staff have something to point to when they tell a patron they owe money, or can’t do something like eat in the library. “I’m sorry, but eating isn’t allowed in here. It’s stated clearly in our policies, on the website.” ↩
4. I know, your provost wants those things on the website. That’s ok. Just understand that no one besides other provosts and librarians will ever look at them and you’ll sleep better at night. ↩

Grand Valley is a SerialsSolutions shop: Summon Discovery Service, 360Link link resolver, and the SerialsSolutions ERMS. While Summon locks us out of changing the user interface, 360Link offers some options for customization. Yet our installation was essentially “out-of-the-box” three years after we launched. In one of our first regular usability tests, it became clear that the poor stock design of the link resolver was an impediment to our users (Figure 1). Our users could not tell which of the links they were supposed to click, since they relied more on visual cues than on text. We observed most users clicking on the name of the database, the last place you want them to click. (The article link is where we want them to go.)

However, when I got under the hood and started making changes to the interface, I realized that I had my work cut out for me. While SerialsSolutions offers the ability to add a custom CSS file, their HTML was so full of syntax errors and depreciated practices that it would be very difficult to make any significant changes without asking SerialsSolutions to make changes on their end. My experience with this kind of request led me to seek another solution, and I realized I could make any of the changes I wanted with jQuery, a lightweight but powerful Javascript library¹.

I had three goals in redesigning our link resolver:

1. Clean up SerialsSolutions bad HTML
2. Change the layout to improve usability and conformity with Grand Valley’s branding
3. Enable progressive enhancement, so that these changes would not lock users into needing Javascript

Inline Styles, we hates them.

360Link is full of nested tables, inline styles, and duplicate IDs. Class names are applied inconsistently, and any custom CSS will just be putting a coat of paint on a bad layout. My first step was to address the obvious HTML errors and remove them.

First, I added jQuery and my own script, 360Link-Reset.js, in the footer section of the 360Link’s administrative interface under Branding². Those are all the changes we need to make to 360Link, although you should certainly include all of your library’s branding.

The first thing I did was remove all of the pesky cruft that SerialsSolutions left in the HTML: inline styles, unnecessary classes, and duplicate IDs. This was handled by the simple jQuery function .removeAttr. Tables were the worst offenders, with initial table tags that look like this in a stock 360Link installation:

<table class="CandyWrapper" border="0" cellspacing="0" cellpadding="0" align="left" id="CandyWrapper">

I needed to remove the border, cellspacing, cellpadding, style and align attributes of all tables, so I added these lines to jQuery:

$("table").removeAttr( "align" );
$("table").removeAttr( "cellspacing" );
$("table").removeAttr( "cellpadding" );
$("table").removeAttr( "border" );
$("table").removeAttr( "style" );

Now, jQuery will remove these attributes once the page loads so the browser will see the following line³:

<table class="CandyWrapper" id="CandyWrapper">

I then repeated the same same procedure with table rows and cells, paragraphs, and spans. Now my 360Link page was devoid of inline styles.

We now have removed all of SerialsSolutions offending inline styles and replaced them with our own. Now let’s start making some more drastic changes.

Everything is in the wrong place

Even replacing our styles won’t let us make serious interface changes to the link resolver, since all of the good content is wrapped up inside of tables (and tables within tables). We need to scrap this table-based layout and replace things with standards-based HTML. The trick is that the information we want to display to our user is locked up within those tables, and it changes with every display of the link resolver. So we need a mechanism to pull the data from the page, store it while we erase the tables, and then place it inside of our new standards-based HTML. Fortunately, jQuery is up to the task. I’ll show you how I replaced the ridiculous citation display table with a standards-based div.

First, we need to grab the data from page. jQuery gives us a lot of options here, and fortunately, SerialsSolutions has used unique IDs for each of the table cells that display citation information. Here I’ll detail those used for articles, which have the format variable set to either “Journal” or “JournalFormat”:

* Author Name (Last, First) = span.fn
* Journal Title = #CitationJournalTitleValue
* Article Title = #CitationJournalArticleValue
* Journal Volume # = #CitationJournalVolumeValue
* Journal Issue # = #CitationJournalIssueValue
* Journal Date = #CitationJournalDateValue
* Article Page Range = #CitationJournalPageValue
* Journal ISSN = #CitationJournalIssnValue

Since these unique IDs change depending on the format of the item retrieved by the link resolver, we first need to make sure we are dealing with a Journal. The first line of our new function is:

if (format == "Journal" || format == "JournalFormat") { 

This way the code will only be executed if the variable “format”, which is set by a script loaded by SerialsSolutions, matches either “Journal” or “JournalFormat.” We’ll eventually want to do a check for every value SerialsSolutions returns for the format variable⁴. [fn: ] Now we’ll grab the values SerialsSolutions has retrieved from their database for these items. I’ll show you how to grab the Journal Title and you can apply the idea to any of the variables you need to grab. The jQuery method text() will grab the textual value shown to the user on the screen and store it as a variable of our choosing.

var journalTitle = $("td#CitationJournalTitleValue").text();

This line first declares a javascript variable, journalTitle, and then assigns it the value of the text inside the table cell with the ID CitationJournalTitleValue. That’s it. We can repeat the process for each of the variables we need on the page, although first we want to add one step to clean up any excess white space in our variable with the jQuery method trim():

journalTitle = jQuery.trim(journalTitle);

Once we’ve finally retrieved and cleaned up all of our variables, we can replace the existing table with a more semantic HTML div with our citation. Feel free to use whichever citation format you want, although we use a bit of a hybrid since we want to display ISBN and ISSN numbers. First, I want to create the div in HTML to make sure it will look the way I want:

<div id="citation">
    <span id="CitationJournalAuthorValue">Smith, Bob.&nbsp;</span> <!-- our js var authorName -->
    <span id="CitationJournalDateValue">(2011).&nbsp;</span> <!-- our js var journalDate -->
    <span id="CitationJournalArticleValue">An Awesome Article.</span> <!-- our js var articleTitle -->
    <!-- etc -->
</div>

The final table has the class of SS_CitationTable, and it is the only table with this class, so the following line will replace the table with our div. We’ll replace our dummy values with our javascript variables, like so:

$("table.SS_CitationTable").replaceWith( '<div id="citation"> <span id="CitationJournalAuthorValue">' + authorName + '</span>. <!-- etc --> </div>');

The jQuery method will replace the table with the class SS_CitationTable with the HTML we’ve included. And with that, we’ve removed one of the pesky tables with some some semantic, standards-based HTML.

One thing we had SerialsSolutions add years ago was a link to export the citation on this page to RefWorks. However, the function was never used because the link was all the way at the bottom of the page, rather than up with the citation where it logically belongs. With jQuery, we were finally able to move it from the bottom of the page and tie in in at the end of our citation to allow students to take advantage of this tool. Getting the value of this link was a little more difficult than citation values, because SerialsSolutions did not include a unique ID to the custom links, and in fact, abuses tables and classes in the custom links area. Since our RefWorks link is always the last link on the page with the class of AnchorButton, we could get the href value with the following method:

var refworkslink = $("a.AnchorButtom:last").attr("href");

However, it is always possible that SerialsSolutions could slap in another anchor link with that class after the RefWorks link. So a better method is to tie this into the static value of the link text, which always says just “RefWorks”:

var refworkslink = $("a.AnchorButton:contains('RefWorks')").attr("href");

The “contains” selector is an incredibly useful tool for grabbing values from vendor pages and rewriting their code. jQuery also supports CSS3 selectors, so you should be able to nab any piece of content and store it in a variable, no matter how crummy the vendor’s code is.

In which we start to hate SerialsSolutions default stylesheet

Now that we’ve moved some things around, we’re ready to start making things pretty with some CSS. But we still have the crummy SerialsSolutions-supplied CSS to content with. I decided to simply replace SerialsSolutions styles with my own, rather than write styles to counteract theirs. Since our replacement code will only be loaded when javascript is available, I chose to remove their styles and load our own styles through jQuery. With jQuery’s remove() method, it was easy.

First, I wanted to remove all of the stylesheets loaded in the element. These are the stylesheets that SerialsSolutions loads automatically. One simple jQuery method will do this:

$("head link").remove()

Now we need to load our own stylesheets. To make it easy to load multiple stylesheets, I created a variable called cssPath, which is simply the path to all CSS files. I first loaded a reset stylesheet that resets the styles on all HTML elements to better ensure cross-browser support, and then I load the custom stylesheet I have created for our link resolver using the append() method, which appends data at the end of an element (in our case, the element):

$("head").append( '<link rel="stylesheet" type="text/css" href="' + cssPath + 'linkresolver.css" />');

The great benefit to this method, rather than adding your styles to SerialsSolutions “Custom CSS”, is that our styles will only be loaded when javascript is available. Users who cannot use javascript for some reason will simply get the terrible HTML SerialsSolution ships with 360Link as well as the default styles, and users with Javascript will get the benefits not only of a rewritten page, but also of better styles to match.

If you have a lot of visitors who don’t have javascript available, you may want to write a stylesheet for SerialsSolutions default styles and load it through the 360Link control panel. Then remove it with jQuery. Users with javascript will still get all of the custom rewrites and better styles we just developed, but users without javascript will have the benefit of some improved styles for the default layout. At the very least, make some changes to the “Article” link to make it more visible.

Caveats

Rewriting vendor websites with jQuery can be a great tool for solving certain problems. It’s great for rapid prototyping of an idea or getting something workable in front of real users quickly, without having to wait for the vendor to make changes or for your development team to build a custom interface using APIs. In these cases, it can be a great first step along the way to a larger development project, but it wouldn’t be a long-term fix by itself. However, there are times when vendor has so apparently abandoned development on a product (like 360Link), that jQuery might be your best option for making dramatic changes. (360Link does have an API, but good luck finding documentation on it.)

This is not necessarily a rock-solid, reliable solution for long-term changes to vendor products, however. For starters, your code is dependent on the bad practices the vendor uses. If the vendor changes their code, even changes IDs or classes, your code will break. In addition, you’re limited to the data the vendor already provides on the page itself. Unlike an API, you don’t have the option of grabbing data that the vendor has stored in a database; you can only grab data that is already displayed on the page. Finally, you must remember that not everyone has javascript, so you shouldn’t require javascript for your changes to at least be functional.

Styling FTW!

We’ve tweaked our layout based on user testing and feedback, and so far things are going well. We’ve also packaged up the scripts we’ve used to make these changes and distributed them on Github, so feel free to grab the source and just plug and play, or feel free to make (or contribute!) changes. Just this week I gave a little talk at Code4Lib Midwest in Chicago on the progress we’ve made using jQuery to “enhance” hosted vendor websites. I focus mostly on 360Link, but I also talk about some work we’ve done with getting CONTENTdm to use remotely-hosted video (and HTML5 video, at that) as well as some progressive enhancement work we’ve done with our institutional repository. You can grab the slides from that talk below.

1. As an added bonus, you can make immediate changes to 360Link when employing this method. Since 360Link updates only once a day, any changes you make through the SerialsSolutions administrative console take 24 hours to be applied. But since the only real change you’ll make to the console is to include a javascript file which handles all of the interface changes, changes to the javascript file are applied immediately. ↩
2. Including your own scripts in the footer section allows the browser to render the page before loading scripts, as well as allows users to see content even if the script fails. You should do this whenever you can. ↩
3. if you View Source in your browser, you will still see these attributes. But if you use Firebug or Safari and open the Web Inspector, you’ll see that the DOM as rendered does not include these attributes. ↩
4. You can see the variables I’ve discovered both in the source code for 360link-reset. ↩

A great example of typeface appropriateness are the neighboring schools in Cambridge, Mass Harvard University and Lesley University. They are literally across the street from one another, but each uses their typeface to tell you what kind of school they are: Harvard uses Georgia for its text, although that first choice is likely because Utopia, the more elegant and “Harvard-esque” typeface, is not a very commonly installed font². Helvetica is the sans-serif compliment that is relegated to small text and links. These use of so much Georgia on the page says that Harvard is a sophisticated, elite school. Lesley uses the same typefaces: Georgia and Helvetica, but in exactly the opposite proportion. Helvetica is the predominant typeface, with Georgia buried in secondary pages as the typeface for quotes and news headlines. Helvetica is a light, modern face that is practical and highly readable. They say that Lesley is a school unburdened by the trappings and rituals of history.

I thought about these choices a few years ago when I worked with the Seidman College of Business to redesign their website. As West Michigan’s premier business school, they needed a sophisticated, modern visual identity. Their website at the time was the default University template, which used the font Arial (with Helvetica as a backup) for nearly everything.

Arial does not scream “business school” to me:

Arial is a sans-serif typeface, which means it does not have the little details at the end of each stroke, and seems more casual than you would expect from a reputable business school³. (This has as much to do with the typeface as it does with what we associate with business schools.) Look at the same phrase in Didot, an elegant serif typeface with very thin strokes:

Which of the two business schools is better? In my unscientific survey at the office, 100% of respondents picked the school that used Didot. And why? Because it looks more refined, more sophisticated, and moneyed. Exactly the qualities we expect from a good business school.

So when redesigning the Seidman website, I switched the headings of the over to Georgia, a sophisticated but not snobby serif typeface that was designed for the Web. It looks great in all caps, lending an air of class, but it doesn’t have such slender strokes that it seems better than you. Georgia is a serif typeface that wears a suit, but still mows its own lawn on the weekends in shorts and a t-shirt.

I felt it was the perfect face to balance Arial on the business school website, because visually it says business school while still staying true to Grand Valley’s identity.

One recent advertising campaign for Grand Valley State University also does well, I think, in choosing typefaces. GVSU is a state school known for quality teaching, affordable prices, and a great football team. We’re not known for research, endowments, or ivy and brick. In the past, our marketing teams paired very elegant fonts like Optima and Palatino that seem to be claiming that GVSU is a very different school. However, the most recent ads and publications return things to normalcy by using what appears to be League Gothic, a great workhorse sans-serif, paired sometimes with Georgia.

So what does this have to do with libraries? Everything. Take the following example. What kind of library do you think this is?

If you guessed Children’s library, then you’re starting to understand how typeface choice tells us a lot about the identity of the institution the letters represent. (If you said “public library,” then that is just a sad commentary on the state of public library design budgets.) As a side note: please never use Comic Sans. For anything (except maybe a lemonade stand sign).

Now look at this library:

This is Garamond, the typeface of choice for the Newberry Library, an independent research library in Chicago with an amazing collection of manuscripts and rare books. Can you imagine their logo in Comic Sans?

The old expression that it’s not just what you say, but how you say it could be applied to the selection of fonts: it’s not just what you write, but what font you display it in⁴.

So when redesigning your library’s logo, your website, or making a sign for the bathroom door or the circulation desk, take this advice: know your library, then pick a typeface that suits you. Smart companies pay people a lot of money to make these decisions, and while we don’t have the money these choices are just as important.

1. The difference between a typeface and a font was succinctly summarized by Norbert Florendo as “font is what you use, and typeface is what you see.” I am sure I misuse them in this article. ↩
2. Until recently, specifying a font on the Web was a probability game, since the viewer had to have the font installed on their computer. So you’d specify the font you’d like to show, in this case, Arial, and then give backup options in case that font wasn’t available. ↩
3. Not all sans-serif typefaces are casual. Museo Sans is a wonderful, sophisticated sans-serif typeface. ↩
4. Frank Chimero demonstrated this in a talk from SXSW earlier this year by resetting the New York Times in Comic Sans. (See slide 20). ↩

I thought that other libraries might be interested in creating their own search plugins for Summon and Millennium². I’ll walk you through creating the files, adding autodiscovery to your website, and creating an installation link. It shouldn’t take more than 10 minutes.

OpenSearch for Summon

In your favorite text editor, open the template below:

<?xml version="1.0" encoding="UTF-8"?>
<OpenSearchDescription xmlns="http://a9.com/-/spec/opensearch/1.1/" xmlns:moz= "http://www.mozilla.org/2006/browser/search/ ">
<ShortName>LIBRARY NAME</ShortName>
<Description>Search library holdings with Summon</Description>
<InputEncoding>UTF-8</InputEncoding>
<Image width="16" height="16" type="image/x-icon">PATH/TO/favicon.ico</Image>
<Url type="text/html" method="GET" template="http://YOURLIBNAME .summon.serialssolutions.com/search?s.q={searchTerms}"></Url>
<Url type="application/opensearchdescription+xml" rel="self" template="PATH/TO/OPENSEARCH.xml" />
<moz:SearchForm>http://YOURLIBNAME .summon.serialssolutions.com</moz:SearchForm>
</OpenSearchDescription>


1. Replace LIBRARY NAME with a short name you’d like to see in the browser’s dropdown menu. I used “GVSU Libraries” for our Summon search.
2. Change YOURLIBNAME to the Summon URL prefix for your library. Our Summon URL is http://gvsu.summon.serialssolutions.com, so we put “gvsu” in place of YOURLIBNAME.
3. Create a little icon, called a “favicon,” for your plugin. (Your University probably already has one. Check with your Web team. Here is GVSU’s favicon.) You can convert any image to a favicon with a simple online tool. Upload your favicon to your server and replace PATH/TO/favicon.ico with the URL of this file.
4. Decide where you want to host this plugin and what you’ll name it. Enter the URL and file name in place of PATH/TO/OPENSEARCH.xml.
5. Finally, save your file with the name you chose in step 4 and upload it to your server.

OpenSearch for Millennium ILS

In your favorite text editor, open the template below.

<?xml version="1.0" encoding="UTF-8"?>
<OpenSearchDescription xmlns="http://a9.com/-/spec/opensearch/1.1/" xmlns:moz= "http://www.mozilla.org/2006/browser/search/">
<ShortName>LIBRARY NAME Catalog</ShortName>
<Description>Search the library Catalog</Description>
<InputEncoding>UTF-8</InputEncoding>
<Image width="16" height="16" type="image/x-icon">PATH/TO/favicon.ico</Image>
<Url type="text/html" method="POST" template="PATH/TO/CATALOG/search">
<Param name="searchtype" value="X"/>
<Param name="searcharg" value="{searchTerms}"/>
</Url>
<Url type="application/opensearchdescription+xml" rel="self" template="PATH/TO/OPENSEARCH.xml" />
<moz:SearchForm>PATH/TO/CATALOG</moz:SearchForm>
</OpenSearchDescription>


The catalog OpenSearch XML is a bit more complicated than the Summon script because Millennium uses a different HTTP Request method than Summon³. For this reason, you cannot use the OpenSearch Millennium plugin in Internet Explorer.

1. Replace LIBRARY NAME with a short name you’d like to see in the browser’s dropdown menu. We called ours “GVSU Library Catalog.”
2. Replace PATH/TO/CATALOG with the URL of your Millennium installation. Our catalog is at http://library.catalog.gvsu.edu, so we’d put this in place of PATH/TO/CATALOG. Note: Make sure you leave the “/search” at the end of the path in the tag. The search will not work without it.
3. Use the URL of the favicon you created in the first step in place of PATH/TO/favicon.ico.
4. Remember to choose a different name than your Summon plugin, and use this filename and the path you used for your Summon plugin to replace /PATH/TO/OPENSEARCH.xml.

5. Upload the file to your server.

Installation and Autodiscovery

Adding these lines to the of your website will tell browsers OpenSearch plugins are available:

<link rel="search" type="application/opensearchdescription+xml" title="LIBRARY NAME Summon Search" href="PATH/TO/SUMMON/FILE .xml">
<link rel="search" type="application/opensearchdescription+xml" title="LIBRARY NAME Catalog Search" href="PATH/TO/CATALOG/FILE .xml">

1. Replace LIBRARY NAME with your library’s name.
2. Change PATH/TO/CATALOG/FILE.xml and PATH/TO/SUMMON/FILE.xml to the URL of the appropriate plugin.

Our link for Summon looks like this:

<link rel="search" type="application/opensearchdescription+xml" title="GVSU Libraries Summon Search" href= "http://gvsulib.com/labs/search/gvsusummon.xml">


Use Javascript to create an installation link. Add the following script to your on your page:

<script type="text/javascript">
  <!--
    function installSearchEngine(engineURL) {
      if (window.external && ("AddSearchProvider" in window.external)) {
        // Firefox 2 and IE 7, OpenSearch. Note: Catalog search won't work with IE
        window.external.AddSearchProvider(engineURL);
      } else {
        // No search engine support (IE 6, Opera, Safari, etc.)
        alert("This browser does not support adding search engines. Try Firefox!");
      }
    }
  // -->
</script> 

When creating the installation link, pass the URL of the OpenSearch plugin to this script and it checks to make sure that the browser supports OpenSearch plugins before installing. Here’s our Summon plugin link:

<a href="javascript:installSearchEngine( 'http://gvsulib.com/labs/search/gvsusummon.xml' )" title="Install Summon Search in your browser">Install Summon Search</a>


That’s it. Now your users can search Summon or your catalog right from their browser search bars. At GVSU, we are building these plugins into our lab computer image, but I suspect that only power users will use them (or be aware of them).

Download the templates ZIP

1. Chrome allows you to install OpenSearch plugins, but they aren’t as intuitive as Firefox or Internet Explorer. We’ve created a short tutorial video that explains how to use these plugins in Chrome.
2. Unlike the LibX toolbar, these search plugins are unobtrusive and simple. LibX looks like the spam toolbars that get installed whenever your 11-year-old niece uses your computer to watch Hannah Montana videos.
3. Summon uses GET, which passes the search query along in the URL string, while Millennium uses POST, which passes data in the body of the request. Internet Explorer does not support POST through OpenSearch because Bill Gates hates the internet. I have no idea why Innovative Interfaces, Inc. (the creators of Millennium) uses POST for catalog searches, other than keeping true to their core mission of making their products cumbersome and nearly unusable.

The Web is not Aunt Mildred’s Closet

The underlying problem for most organizations’ websites (and certainly most library websites) is that no one has ever asked why the website exists in the first place. Who is it for? What do we want them to accomplish? Trying to decide if your website is a “success” is useless if you don’t have some idea of what you are trying to do. Simply printing out page views and making a colorful graph isn’t going to tell you anything.

In all organizations, once or twice a week someone stops by the office of the Web Wrangler™ to ask, “can we put this document somewhere on the Web?” The implication is that the person who created it doesn’t know where it should go, so stuffing it into the website seems like the easiest solution. The website then becomes the kitchen junk drawer, or Aunt Mildred’s closet, full of stuff that has no home, but collocated in one place for anyone who needs to find something.

Your website is not a junk drawer. It isn’t Aunt Mildred’s closet. Do you like rifling through your junk drawer? Have you ever found what you’re looking for in Aunt Mildred’s closet? What makes you think your users want to do this?

The point is that if you don’t know where something should go on your website, then your users certainly won’t know where it is. You created it! If you have content that doesn’t either help your users meet their goals or help your organization meet their goals, then it shouldn’t be on your website. It’s just clutter.

So today I’ll talk about how we can make our content useful once we know why we’re creating it in the first place. You can see the slides below. Feedback is always welcomed, via Twitter @mreidsma.

Libraries used to have a monopoly on information, but the Internet changed that. Libraries are only now starting to notice this change. For the past decade we’ve tried to convince our users that searching the library is often a better solution than searching Google. There is nothing wrong with this, since it’s often true. But all of our energy went into making these arguments instead of genuinely improving our user’s experiences. We ignored our clunky, complicated online catalogs, quickly tossed up long, convoluted help pages filled with library jargon, and tried to convince users that on the other side of these unpleasant Web pages lay the research promised land. Every question answered, every need satisfied. It was easy, we said:

Our site is simple. Just type some keywords, select from the radio buttons (Title or Series Title? What do you mean “you don’t know?”). Oh, don’t forget to select your region from the dropdown menu (Are you region #4 or region #5?). Subjects? Well, do you mean LCSH or MESH or Children’s, little Susie? Now just click Find it!

Well, that wasn’t so hard. What could that single search box have that libraries don’t? How about a stake in making great user experiences?

Google cares desperately about it’s users. It has to. Literally billions of dollars a year are at stake, since Google’s entire business model is designed to get people to use and reuse and depend on it’s services. If you use Google’s search, or Gmail, or Google calendar, they can sell your attention to advertisers. They can’t get you to use their services without making the experience the best on the Web. Imagine if Google’s search interface looked like some of our library search pages. Larry Page and Sergey Brin would be working at Jimmy John’s and you’d be asking Jeeves for directions and “Yahooed” would have been a useful word of the year.

One of the reasons libraries seem to be waking up from their jargon-filled delusion is that we suddenly have a financial stake in making experiences better for our students as well. Budgets are getting slashed and library directors are being asked to justify the existence of expensive library resources, especially when so many students skip the library and head to Google.

In her excellent The Elements of Content Strategy, Erin Kissane warns those with monopolistic products that they can’t afford to ignore the needs of their users just because they have no competition. She writes,

If you’re the only one offering a desirable product or service, you might not see the effects of narcissistic content right away, but someone will eventually come along and eat your lunch by offering the exact same thing in a user-centered way.

Kissane, p.9

That’s basically what happened to libraries. Google came along and offered up answers to questions (i.e. information) that was easy to use. It’s not that libraries didn’t care about our users, it’s that what our users wanted us to care about changed, and we decided that our fancy MLS degrees gave us the right to decide that what we thought they needed (comprehensive, subject-specific but difficult to use resources) was more important than what they said they wanted.(ease of use). We just stuck our fingers in our ears and chanted “Our search is better! Our search is better!” How’d that work out for us?

Google ate our lunch.

So now libraries are rushing to hire “User Experience Librarians” and talking about simplifying their websites and jumping on google-like discovery tools like Summon. But will these small changes make a difference? Probably not, because these are superficial solutions. It’s not just that our users want a better gradient on our search buttons, or more white space between results. They want a library that doesn’t yet exist, one that understands that the world has changed and takes that change seriously in its mission and into its makeup.

Part of the problem is built-in to our organizational charts.

Take a look at most academic libraries. They offer a wealth of print and electronic resources, but these are all accessed through the library website. Want to see if the library has a book? Search the catalog, through the website. Access to a journal? Search for it through the website. This means that nearly everyone that walks through the library’s door and everyone that logs on to the website interacts with the library website. So while only a portion (a large portion, granted) of our users walk through the front door, nearly 100% come to the website.

Now look at the organizational chart. How many people are responsible for in-person service? How many people are responsible for the Web? See the discrepancy¹?

Google’s business is online, and their organizational chart shows that. The academic library’s business is largely online, as well, but you wouldn’t know it by looking through a staff directory.

I’m not advocating tossing our organizational structure and hiring a bunch of Web developers. But as libraries continue to fight for resources and as our users move more and more to the Web for everything, we need to be ahead of the game and planning for how our libraries will survive into the next 10, 20, 30 years.

How do we start? Train the people we have. Every librarian on staff should know how to write HTML. Everyone should know the difference between hits, views, and visits. Everyone should understand how a relational database works, and how pages are generated dynamically. Most importantly, everyone should know why these things are important! These are foundational skills that no student can leave library school without demonstrating. These are the necessary skills for being a librarian in 2011².

In the automotive field, mechanics who don’t want to learn how to work on cars with computers are soon out of work. Why? They ignored their users desires to have their cars fixed. If we, as librarians, don’t start taking the Web seriously, we’ll all be sitting on a park bench, feeding pigeons with some mechanics, reminiscing about the “good ‘ol days.”

Epilogue: As I was adding in links for this article, I visited our “premiere” library publication, Library Journal, and found their website in this state, which just goes to emphasize my point.

1. Please don’t make some silly argument like “but building a website takes less work than manning a service desk.” This just tells me that you’ve either never built a website, or have done a poor job at the ones you’ve created. Websites take constant attention, testing, and updating to stay relevant and usable. Think of how often Facebook changes its layout. Think they do that because they want to annoy you, or get you to join another “1,000,000 users against the new Facebook Layout” group? No. They change the layout to make the site more usable, which keeps you around longer, which gives them more of you to sell advertisers. In short, they change the layout because they have to care about users. ↩
2. Foundational skills are important, not just blind allegiance to technology at all costs. Start by understanding how the Web works and why that is important, not by pasting up QR codes on every book range. ↩

When it comes to collections, we aren’t curators as much as custodians. The job of a curator is to separate the wheat from the chaff, and that runs counter to the librarian’s call¹. But the problem is that users have specific needs, and the job of sorting through the ever-growing pile of resources is handed over to the user. This behavior finds its way into our technology adoption, as well. We want to offer every new technological marvel, somehow, to our users. There has to be value somewhere, right? We try things out, and when the next new thing comes along, we toss our formerly-beloved gadgets into the closet.

Five years later, we read an article about how some library managed to stop the merry-go-round long enough to successfully integrate some older piece of technology to actually improve user experience. We have a committee meeting, and someone remembers that we bought a dozen of these whiz-bangs five years ago, and we dust them off and follow the lead of another library. But then we climb back on the technology train, having learned nothing from the experience, content to let others handle our curatorial responsibility of asking if the technology meets our users needs. This is what keeps us five years behind.

When we inundate ourselves with the latest gadgetry without performing some essential curatorial functions, we lose focus on what’s important, which is helping our users. We adopt technology for technology’s sake, and have no time to learn and really integrate new technology because we’re always moving on to the next big thing. We sense that there is something that can be improved about the way we provide service, and we’re sure that this next gizmo or that whiz-bang will fix the problem. But it won’t, because the problem isn’t that we’re missing the right piece of technology. The problem is more fundamental.

Users have work to do at academic libraries, and that work does not require technology². We should adopt technology because it makes our users’ work easier. When you think of the best technology you’ve ever used, wasn’t it great because the gadget got out of the way and made your work easier? Ignoring the reasons why we use technology in the first place will only pile up technological barriers between our users and what they are trying to do.

We need to become technical curators. We need to understand what are users really are doing or want to do (and not what we think they are doing or want to do). Using that information, we should evaluate every piece of technology that is proposed. How will this help users do their work? Will this make their work easier, without burdening them? Will this have longevity? Do users even want what this provides? (I’m looking at you, QR codes.)

As Merlin Mann says, if you want to make lists, don’t buy a new notebook. Just make lists! If we want to provide better service for our patrons, no technology is going to do that for us. If we want to provide great service, we need to start by providing great service. Technology should only build on that foundation, not try to mask fundamental problems.

1. Librarians pride themselves in offering up access to as many resources as we can. Collection development librarians perform some high-level curation to ensure that the resources match the collecting goals of the library. But this isn’t strict curation. ↩
2. Yes, I realize that if something is online, technically you need a computer to read it. Unless, of course, the text is printed out for you. But here the technology involved, an Internet-capable computer with a Web browser, actually makes searching for articles much easier than sifting through paper stacks. Research can and still is done without any online component, and this is primarily what users are doing in academic libraries: research. ↩

Design is not one task among many, something you use to paint a facade on your working website. It's a mindset, a framework through which the whole act of creating needs to be seen. Every decision is a design decision, and seen this way, the parts of your website need to do more than just add color. Changing the link color isn't going to improve a list with too many elements. Adding a photo isn't going to make users any happier about navigating a clumsy interface. And adding gradients certainly isn't going to make up for a nonsensical taxonomy. The old idea that form (design) and function are in conflict is misguided. Form and function are two sides of the same coin; how something works and how something looks are intimately linked.

We build websites for users, but it's hard to think of users when you parcel off design into an afterthought. If design is relegated to an aesthetic afterthought, then we distance ourselves and our website from our users by putting a ill-fitting veneer over a poorly built structure. Our users now have to muscle their way through a layer of questionable aesthetics even to get to the content of our site.

When libraries held a monopoly on information, we might have been able to get away with this disregard for our users. Where else were they going to go? But that time is a sweet memory, and we've lost the battle in trying to convince our users that if they just cut their way through the brambles and piles of garbage to get to the Very Expensive Database™ we provide for them, their research will be easier. It's not easier, and even if the content inside that Very Expensive Database™ is more relevant and more trustworthy than what can be found on Google our users don't see the point in wrestling with our poor design choices to get their work done.

1. Marco Arment has summed up why this view is bad for users by looking at the role of design in Android phone development: “Nearly every usability detail appears to be an afterthought, as if ‘design’ is relegated to a coat of paint at the end of the development cycle rather than a deep-rooted philosophy throughout it.” ↩