Posts Tagged ‘OPAC’

The Athens County Public Libraries are members of the Ohio eBook ProjectOhio Digital Library, a consortium of libraries who contribute to and share access to a collection of eBooks and other downloadable material through OverDrive. In order to make these resources more discoverable by our patrons we add MARC records for these titles to Koha.

When we started doing this we felt that it was important for the patrons to be able to tell very easily that the title they saw in search results was an electronic resource they could download. We already have many records in our catalog for web sites. We were concerned that these two types of resources would be difficult to distinguish.

An electronic resource in default OPAC search results

Since Koha gives us the ability to inject custom JavaScript into our OPAC, a JS-based solution seemed like the best option. The goal was to be able to use JS to examine each search result and look for a clue that any particular result was an Ohio eBook Project record. Luckily all the OEP records have something in common: A URL (stored in the MARC 856u) beginning with “http://ohdbks.” Here’s the JavaScript I came up with:

We loop through each td within the table inside #userresults, storing the index of each iteration as i.

The matched td is stored as a variable for easy reference.

The script finds an anchor tag which matches the string we’re looking for and stores that in a variable.

We want to refer later to the <a> tag’s parent container, so we use jQuery’s parent() to store that as linkc.

We pull the href attribute value for the previously select <a> tag.

If an href was found…

…hide the availability and “actions” (“Place hold,” “Add to cart”, etc.) elements which we don’t consider relevant to e-resource records.

Replace the contents of the original anchor tag’s container with new html which uses the previously-saved href attribute but changes the text of the link and adds a special CSS class.

We chose to label each eBook link “Check the Ohio Digital Library for availability” because Koha has no way of knowing whether a particular title is checked out. The link is styled by CSS added to Koha’s OPACUserCSS system preference:

Electronic resource detail page

When the patron clicks to view more information about one of those electronic resource titles they come to a detail page which presents additional opportunities to simplify the display for this type of record.

Since this kind of title is available only through the Ohio Digital Library web site we don’t actually have any local holdings, but when we add MARC records for these resources we include a dummy item to which we can attach some additional information. One reason for this is to be able to have a searchable collection code attached to each record. But showing holdings information to the patron isn’t very useful because none of it is relevant:

Holdings information displayed by default for electronic resources

Another aspect of the detail page which is less than ideal is that the link to the Ohio Digital Library is pretty well hidden in the other details about the title like publisher, subject headings, etc. We again turned to JavaScript to solve both of these problems at once:

This code is very similar to what we used on the search results page, but a little simpler.

Again we trigger this function when this particular area of the page (“span.online_resources”) has completed loading.

We find the link to the Ohio eBook Project download page and store the href attribute.

If an href was found…

Replace the holdings table (identified by theID #holdings) with an image which links to the OEP download page.

In four lines of JavaScript both goals are accomplished: The meaningless holdings table is gone, and a prominent link is added to the Ohio eBook Project download page for the title the patron is looking at.

It’s been almost three years since I wrote Colorizing the Cart and Lists buttons. My conclusion then was that we needed a fairly complex combination of markup, CSS, and background images to create the appearance of the buttons.

This works fairly well in Firefox, Safari, and Chrome. Unfortunately, it fails not only in Internet Explorer 6, 7, and 8, but all versions of Opera too. For the time being, our more-complex process gives the desired result to a wider audience.

The time has come for the simpler version. My patch for Koha bug 7584, “Update cart and lists buttons style using CSS3 features” has just appeared in Koha’s master branch, the development version which precedes an official release.

What has changed? Firefox, Safari, and Chrome have had updates since then, which has at the very least expanded the number of users of those browsers who are on a more recent version. Opera, one of the holdbacks in 2009, now supports the features required. Internet Explorer 6, 7, and 8 still linger of course, but Internet Explorer 9 is available now. IE9 offers better support for the features we need.

For me what has changed is that I now think that Koha should be a little more aggressive about taking advantage of the features of up to date browsers even if that means the experience isn’t the same for users of older browsers.

The new style

Let’s take a look at the revised markup. Where the previous version needed a lot of extra elements (<i>, <span>, etc) the new version doesn’t:

Notice the variations: “-webkit-border-radius” is specific to Chrome and Safari. “-moz-border-radius” is specific to Mozilla-based browsers like Firefox. When we specify a single value like “5px” the value is applied equally to all four corners. You can also specify different values:

The values are applied clockwise starting with the upper left-hand corner.

Background Gradients

The other primary aspect of the buttons are their background colors. Previously we used a transparent image to give the button background a gradient. With CSS3 we can specify the gradient values right in our CSS. The easiest way to accomplish this is using the Ultimate CSS Gradient Generator.

A web-based tool for designing CSS gradients

With the CSS Gradient Generator you can use the visual tools for creating a gradient and the CSS will be generated for you. It generates CSS declarations specific to several major browser versions including Internet Explorer. There is even an option to upload a gradient image and have the Generator automatically match the colors.

Eight lines of CSS each doing the same thing for different browsers, starting with a solid background color for browsers which don’t support CSS3. This is the same kind of code which will be generated by the CSS Gradient Generator with one exception: The OPAC CSS also includes a background image for the Cart button in order to display the little cart icon.

There’s more to the styling of the buttons than rounded corners and background-gradients, but nothing which we haven’t seen before. Fire up Firebug (or your favorite browser’s DOM inspection tool) and inspect the buttons for more information.

What have we gained?

Just looking at the HTML markup it would seem we’ve gained a lot of efficiency over the <span>-heavy buttons in the older version. But the multiple lines of CSS more than make up for it. What advantages does the new design offer? Importantly, flexibility. We don’t have to create custom-colored 24-bit transparent images when changing the background color of the search bar. We can make all our changes, including changes to the Cart icon, right in the CSS. Border color, border radius, background-color (or gradient), it’s now 100% CSS and can be affected by a custom stylesheet or by changes to the OPACUserCSS system preference.

This change is going to require some revisions if your library has existing CSS customizations to these areas of the OPAC, but I think going forward these changes are going to prove to be beneficial to those seeking to customize their OPAC’s appearance.

Koha’s OPAC has a feature which lets logged-in users leave comments about records in your catalog. This feature was originally branded as “Reviews,” but was changed to “Comments” in order to align it with the familiar feature allowing users to comment on content in blogs, on YouTube, etc. If you haven’t seen it before, here’s what it looks like to a logged-in user:

A catalog record with comments

If you visit the Athens County Public Library catalog you’ll find that comments are enabled, but few users have taken advantage of the feature. I’ve often wondered what we could do to encourage people to add their comments, and one of the ideas I had was to feature recent comments–perhaps on the OPAC or library web site home page.

I’m not an experienced Perl programmer. Most of the changes I make to Koha’s Perl code are minor or cut-and-paste. Adding a feature as unformed as a recent comments view was a little daunting, but I think it turned out well, and I hope I did it right! I’m quite pleased with the result:

Recent comments

The page shows the latest comments added to any title in the catalog in descending order by date. The page also offers an RSS feed of recent comments. This offers two benefits: First, patron can subscribe to recent comments if they want to find out what others are talking about; and second, the library can use that feed to pull content into their own web site. If my library site’s content management system can process an RSS feed, I can add those recent comments on my library’s web site too.

Of course it’s too late in the development cycle for this feature to make it into 3.2, but I hope it will arrive with 3.4.

A collaborative process

There’s one more thing I wanted to share about the development of this little feature: When I was creating the RSS feed I was testing it with the W3C’s feed validator to make sure I had constructed the markup for the feed correctly. The only error I didn’t know how to fix was one with date-formatting. The validator told me I needed to format my date according to RFC 822, but Koha didn’t include a way to format dates that way. I put out a plea on the Koha IRC channel which was answered by Chris Nighswonger. He very generously added the code I needed and I was able to include a valid RSS feed.

This anecdote shows the very best kind of interaction possible when you work with an open community of developers. I’m not suggesting that in the Koha world all one has to do is ask and free code will be provided. But sometimes you catch someone at the right moment, or the challenge appeals to them, and they pitch in. Many thanks to Chris for doing so when I needed help.

Seems like lots of people hate the login form on Koha’s OPAC. I understand many have a problem with it because their users look at and think they must log in to use the catalog. There’s no switch to flip to turn off display of the login form on the main page, but you can use a little custom CSS to hide it.

Add this to your OpacUserCSS system preference:

#login {
display: none;
}

One disadvantage to this technique is that it doesn’t allow your main page content to take up the whole width of the front page. The right-hand column of the OPAC’s main page remains pretty much inflexible in terms of content.

What if you don’t want to eliminate the option of logging in from the home page but you don’t like the big login form? Recently someone posed this question on the Koha mailing list.

Any thoughts on where to look to move the “Login to Your Account” and the Username and Password blanks to the top and replace the link there for “Login to Your Account” with Username and Password?

I started jumping in with some JavaScript when I realized this could be accomplished using just CSS. Here’s the result:

Click to enlarge image

Here’s a rundown of what’s going on in the custom CSS:

Styling the form container with position: absolute and placing it in the top right corner. The form overlaps and hides the default login link in the top right corner.

Styling all the form contents as inlineinstead of block.

Adjusting margins, padding, font-size, and width.

Hiding the login form’s title (“legend”).

Why did I hide the form’s title? It wasn’t for aesthetic reasons. I found that Internet Explorer 6 refused to display the title (which is a <legend> inside a <fieldset>) in line with the rest of the form. IE6 wanted to give the <legend> its own line. Some conditional comments could alleviate the problem if you wanted to deliver the title to browsers that can display it correctly.

To give the form some room there at the top of the page I added a little bit of margin to the top of the main search bar. If your OPAC design includes custom header content you might have to adjust that margin.

I’ve tested this in these browsers on Windows XP: Internet Explorer 6, Firefox 3.5, Safari 4, Opera 10, and Chrome 3. Below is the CSS in its entirety. Add it to your custom stylesheet or to your OpacUserCSS system preference.

In a previous post I talked about YUI Grids and how we use them to structure Koha pages–all very abstract unless you’re interested in designing Koha pages. But there are some opportunities to use the Grids techniques in OPAC customization.

Two OPAC system preferences, opacheader and OpacMainUserBlock, are good candidates for some Grids experiments. Both let us add our own HTML markup to the Koha OPAC design, and both are placed within the default page structure defined by the Grids framework. That should let us use our own structure of grids and units to create containers for our content.

Let’s start with opacheader, and the basic grid/unit example of two equal-width containers, or columns:

Customizing OpacMainUserBlock

OpacMainUserBlock is the place where it would be the most useful to leverage the Grids framework’s power. The main page of the OPAC is a blank slate for your library’s custom content. It would be great to be able to use the built-in grids system for laying out that content.

Let’s try the same sample markup from the previous example. Two easy and equal-width columns, right? Wrong:

Click to enlarge screenshot

What’s going on? That doesn’t make sense, does it? Well…It makes a certain amount of sense. We have to remember that when dealing with OpacMainUserBlock we’re already working within an existing grid:

The default structure of the OPAC main page, non-logged-in state

The OPAC template for the main page defines a grid with a 75% block (“yui-u first” in the diagram above) and a 25% block (“yui-u”). That means that when we add markup to OpacMainUserBlock, we’re adding that markup within a <div class=”yui-ge first”>. The YUI Grids documentation tells us that if we want to nest grids we should do so by nesting <div class=”yui-g”> directly. Try this in OpacMainUserBlock:

Better. Usable, anyway. But why did we get another 75%/25% split? We didn’t add a grid with the “yui-ge” class. To be honest, I’m not sure whether there is any way to avoid getting the 75%/25% split when we nest a grid here. It seems that any time we nest a grid inside a “yui-ge” grid, we get another “yui-ge” grid. In other words, it’s turtles all the way down:

Click to view example

Not freedom, only some flexibility

It seems were left with very limited choices if we want to try to leverage YUI’s Grids system in the context of OpacMainUserBlock. If you’re content with a 75%/25% split, then you’re okay. Otherwise you’re on your own to define a content layout your own way.

Now that you’re happily (or at the very least, somewhat tediously) customizing your additional search links, your future is bright and worry-free, right? Not quite. I submitted a patch recently to the Koha project which makes a change to the OPAC template, altering the way the additional searches are displayed. Instead of showing all the search links by default, in Koha 3.2 the links will be hidden and displayed in a drop-down menu.

Click "More searches" to display a menu

Why the change? To conserve screen real estate. Some libraries were finding that with lots of data in the holdings table, and lots of options in the menu which includes the additional search links, content was overlapping and becoming unreadable. Here’s an example from the Koha bug report:

Click to enlarge screenshot

My change to the template alleviates the problem in two ways: by collapsing the additional search links, and by hiding the left-hand navigation menu on this page. The latter decision may generate some heat. I felt it was a fair trade-off in order to have a non-broken display, but if others disagree I hope I’ll hear about it.

Coping with change

What does this mean for those of us who have customized their search links? Luckily, only a few changes to the code we covered previously:

First, the HTML element we’re appending a list item to has changed to “#furtherm ul.” That identifies the list which is being used to construct the menu.

Second, there are some additional classes being added along with our list item. The classes are there so that the additional list item is styled properly along with the other menu items. The new menu is being created using YUI’s Menu component.

If you’re running the most recent development version of Koha, you can try the revised JavaScript. Here’s the result:

Our custom link has been added to the menu

If you’re not running the most recent development version, bookmark this page for later reference. When your Koha installation gets updated, you’ll need to revise your script!

On every record’s detail page there is list of links in the right-hand sidebar for searching for that title on a few other sites: Worldcat, Google Scholar, and Bookfinder. These were chosen as reasonably generic choices for a wide audience. The trouble is, generic doesn’t work for everyone: For many libraries these links aren’t appropriate. They’d like to be able to take out one or more of them and/or add their own. Unfortunately these links are hard-coded in the template. Until someone contributes the time or money to develop a solution, we have to resort to JavaScript trickery to accomplish it.

JavaScript Trickery

jQuery to the rescue. If we use FireBug to inspect the page we can see that the “box” the links are in has a unique ID. That’s perfect as a place to tell jQuery to start looking.

Click for full screenshot

Let’s start by adding a custom link to this menu. We start our JavaScript by targeting the #further div. Since we want to add an item to the list contained within the #further div, we’ll add that to the selector:

Okay, drop that into the opacuserjs system preference and refresh your OPAC page to see how it worked:

Updated list of links

Great! We’re done, right? Well… The trouble is, the link we added doesn’t include any means to pass the title to the search system on the other site. How are we supposed to do that? Luckily, many sites are very open in the way they perform search requests. You just have to do a little digging. Let’s go to Paperbackswap.com and do a search to see how they handle it. Since I know we’re going to pass a title to their search system, I’m going to look for a title-specific search. I found one on their advanced search page. Plug in a title and look at the resulting URL:

Seems to work just as expected. Now we know that we can use a link like this to pass our own search term to the site:

http://www.paperbackswap.com/book/browser.php?phrase_k1=<title>

Using JavaScript to find the title

Click to enlarge screenshot

We’re building the custom search link with JavaScript, so we’ll have to find a way to leverage the same tool to grab the title. Luckily there is a unique element on the page which contains the title, and we can grab it using jQuery: the <h1> tag. Okay, so there are two <h1>’s on the page, a little bit of a technical foul on Koha’s part. Using FireBug we can ispect the <h1> containing the title and we can see it is contained in a uniquely identified container. We can grab the contents of the heading this way:

The problems arises because the subtitle is marked up with a <span> inside the
<h1>. When we grabbed the contents of the <h1> tag, we also got the <span>. We’ll have to do some more JavaScript trickery to drop the <span>. Here’s what I came up with, thanks in part to this demo:

The Athens County Public Libraries have been using Koha 3 since February 2009. Since that time there has been a feature available to patrons which hasn’t really been used: tags.

The Koha 3 OPAC offers feature where users can “Tag” records with keywords. Tags are generally used as a sort of user-generated subject heading, sometimes called a “folksonomy” because it’s a taxonomy created by regular folks.

If you browse around Flickr you’ll find that on each photo page there is a list of keywords found in the right column, labeled “Tags.” Take a look at one example, a picture of the New York Public library. The photo has been tagged with “New York City,” “Spring Break,” “vacation,” “Manhattan,” “New York Public Library,” and “architecture.” If you click on one of those tags, you’ll see all the other photos by that user which were tagged with the same keyword. Then you can click the link to “See all public content tagged with newyorkcity”

The nice thing about tagging is you don’t have to pick from a preselected set of categories. As you can see from the above example, you can categorize things not just by what they are in and of themselves, but what they are to you. The picture must have been taken during Spring Break vacation, and the user tagged it that way so that he could find all those vacation pictures at once.

Del.icio.us is a “social bookmarking” site. After creating a free account you can bookmark sites for later use, and add tags to help categorize them. Take a look at one of the other common features of systems which allow tagging: the tag cloud.

A tag cloud is both a menu and a visual representation of all the tags (or at least the most popular tags) in a system. In the Delicious example, “blog” and “design” are the largest terms in the list because they’re the most popular (with 6,769,771and 9,195,968 entries each, respectively!).

Koha 3 has this same functionality. If a non-logged-in user pulls up the details of a record in the OPAC, they’ll see “No tags from this library for this title. Log in to add tags.”

No tags yet!

How can this be of use to the patrons? What if you’re a kid looking for graphic novels, but they way you’d think to search for them would be to look for manga. Some of the hits you get will be relevant, but not everything. That’s because a lot of what you’re looking for is classified as Comic books, strips, etc. –Japan. If you’re a manga fan, you might look for your favorite titles and tag them so that you’ll be able to find them easily next time.

If you log in to the OPAC and add some tags, at first the only person who will see them is you. We have tag moderation enabled in Koha. A staff member can periodically check the list of tags and approve or reject them. If a patron-created tag is approved, it will show up in Koha’s tag cloud. If a tag is rejected, it won’t disappear from that patron’s personal set of tags, it simply won’t show up in the public list.

Tags in the OPAC have have critical, practical difference from tags on Flickr or Delicious: tags aren’t being used to categorize user-generated content. On Flickr, the user has a vested interest in tagging photos as they’re created, because it will help them keep track of their photos in the long run.

In the OPAC, records are created by catalogers, and patrons are accustomed to using standard methods (e.g. keyword searches) for finding them. I’m not sure what would motivate an OPAC user to take an active role in tagging items. The example I used of a book for which the “official” category didn’t match the user’s understood category is the one I would think would be most common.

Is that enough? For tags to be beneficial not just to the individual but to the general audience of OPAC users, the pool of existing tags may have to reach “critical mass.” Users clicking through to the tag cloud are sure to lose interest fast when they see nothing! I’m hoping to enlist the staff here to brainstorm about some useful tags and maybe get the ball rolling.

Have you ever been unable to find something in the library because it was categorized differently than you expected?

Koha uses the Yahoo! UI Library Grids CSS framework for both the OPAC and the staff client. When we revamped the Koha interface for 3.0 the Grids framework was chosen because it would simply the process of structuring pages while giving us a pretty good selection of possible layouts.

A nice feature of the Grids framework is that you can control the layout of your page with relatively minor changes in markup. Here’s an example for one of the basic layouts:

You can see that YUI’s Grids framework suffers from the same problem a lot of CSS frameworks have: the class names are pretty nonsensical if you’re not used to them. I consider this to be par for the course: Better that they be nonsensical than have semantic-sounding names which aren’t appropriate for your actual page structure.

How does the framework make it easy for us to change page layouts? I’ve put together a simple example. This example uses JavaScript to swap out one class name. Try it and see how much can change based on one class name:

Click to try the demo

The above example shows how the “primary” page structure can be changed. I say primary because you can only choose one of those layouts at a time. If you want to have additional columns or blocks within that layout you can use “grids” and “units” within that main page structure:

Just like with the page structure, there is a set of pre-defined grid structures you can use within your page. The simplest is a set of two equal-width containers:

Just like with the page structure example, a change to the grid’s class name can affect the layout of the units within it. Notice that the grid/unit structure is changing within the page structure we defined before: a single main block with a left-hand sidebar:

Click the try the demo

The power of the framework’s grid/unit structure really comes into play when you start nesting grids within grids. Start with a grid which creates two equal columns, and then nest the same two-column grid within each of those columns:

In the markup above, instead of nesting a unit (‘<div class=”yui-u”>’) inside a grid (‘<div class=”yui-g”>’), we’re nesting a grid inside a grid. The containing grid can still be altered to change the layout of the units inside it:

Click to try demo

The Koha OPAC’s grid structure

How is this implemented in the Koha OPAC? Koha has to take advantage of the Grids framework’s flexibility when obeying different conditions in the OPAC. Take, for example, the main page of the OPAC. There are four possible layouts the user might see based on state and system preferences:

No OpacNav, not logged in

No OpacNav, logged in

OpacNav, not logged in

OpacNav, logged in

Using some logic in the Koha templates, the layout can be easily altered based on each of those conditions. And because the Grids framework makes it so easy to switch between those different layouts, the template can be much simpler:

The template logic can check one condition (whether the OpacNav system preference is populated) and alter the page layout accordingly.

What does this mean to me?

Unless you’re hacking Koha templates you won’t many opportunities to build your own grids. However, there are a couple of instance where you might want to try it, and I’ll talk about that in my next post.

One of the nice things about using an open, web-based OPAC is it’s really easy to share and reuse links to stuff in your catalog. One great way to promote aspects of your collection is to share a link to a specific search. The Athens County Public Libraries do this with a button on our OPAC. Try it:

When you click that image you’re taken straight to search results for new DVDs. We didn’t have to create a new collection code or shelving location, we just use built-in options for performing advanced searches. Here are the steps we took to come up with that result set:

The “Newest to Oldest” search guarantees that the most recently added items are at the top of the list. True, this isn’t as fine-grained as a search that would let us put in a specific date range (“DVDs acquired in the last 7 days”). And it may not meet every patron’s expectations because it shows returns recently acquired items, meaning if you add a new copy to an existing record it will show up in those results. But for patrons hungry for the newest DVDs it will works very well.

The nice thing about promoting your collection this way is that you don’t have to maintain a hand-picked list. Want to promote the anniversary of the moon landing? How about a link to a search for the subject “manned space flight?” It’s a great quick way to draw your users into the catalog with timely, topical points of interest.