Monthly Archives: July 2009

Understanding Tags

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.

Some might be familiar with two sites which were among the first popularize the idea of tags: Flickr.com and Del.icio.us. We used Flickr recently to share pictures of the Wells library reconstruction following a fire in June 2008.

Flickr tags list

Flickr tags list

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!

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?

YUI Grids and the Koha OPAC

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:


<div id="doc">
<div id="bd">

<div id="yui-main">
<div class="yui-b">
<p>Main Content</p>
</div>
</div>

<div class="yui-b">
<p>Sidebar</p>
</div>

</div>
</div>

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:

yui-layout-demo1

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:


<div id="doc">
<div id="bd">
<div class="yui-g">

<div class="yui-u first">
<p>First grid unit</p>
</div>

<div class="yui-u">
<p>Second grid unit</p>
</div>

</div>
</div>
</div>

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

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:

<div id="doc">
<div id="bd">
<div class="yui-g">

<div class="yui-g first">

<div class="yui-u first">
<p>Unit one, sub-unit one</p>
</div>
<div class="yui-u">
<p>Unit one, sub-unit two</p>
</div>
</div>

<div class="yui-g">

<div class="yui-u first">
<p>Unit two, sub-unit one</p>
</div>
<div class="yui-u first">
<p>Unit two, sub-unit two</p>
</div>
</div>
</div>

</div>
</div>

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

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:

opac-layout-no-opacnav-logged-out

No OpacNav, not logged in

opac-layout-no-opacnav-logged-in

No OpacNav, logged in

opac-layout-with-opacnav-logged-out

OpacNav, not logged in

opac-layout-with-opacnav-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:


<!-- TMPL_IF NAME="OpacNav" -->
<div id="doc3" class="yui-t1">
<!-- TMPL_ELSE -->
<div id="doc3" class="yui-t7">
<!-- /TMPL_IF -->

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.

Using custom search links to promote your collection

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:

See our Newest DVDs

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:

  1. Go to the advanced search page.
  2. Check boxes to limit the search to DVD collection codes.
  3. Choose Sort by: Dates -> Acquisition Date: Newest to Oldest.
  4. Search.

The URL of the search results page is the one to copy and re-use.

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.

If you like my “new DVDs” image, you’re welcome to use it. It uses a DVD icon found on Wikimedia Commons. Here are a couple additional choices:

new-dvds-bridge

You might want the above image if you’re using the “Bridge” icon set in your OPAC already.

new-dvds-tango

The above image uses a modified version of an icon from the Tango Icon Library. Check out the other Bridge and Tango icons for more choices that might inspire your own material-specific promotions.

Add a Koha login form to your web site

opac-login-on-library-site

This question came up on the Koha mailing list today: How can I add a Koha login form to my library’s web site? Luckily it’s really simple. The image here is of the one we added one to our site.

Everything you need to know about how to do it is right on your Koha OPAC home page. Just view the source for the login box and copy it! Here’s the simple version, adapted right from the source:


<form method="post" action="http://path.to.your.opac/cgi-bin/koha/opac-user.pl">

<label for="userid">Login:</label>
<label for="password">Password:</label>

</form>

The only thing you’d need to change to make that snippet work for you is the path.to.your.opac part. Replace that with the full URL of your Koha OPAC, e.g. http://acpl.kohalibrary.com.

You could even do the same for the staff client, for instance if you wanted your users to be able to log into the Koha staff client from your library’s intranet:


<form method="post" action="http://path.to.your.staff.client">

<label for="userid">Username:</label>
<label for="password">Password:</label>

</form>

Of course I wouldn’t recommend putting a login form for your staff client anywhere in public view. Note that using that form will log you in to your default library. If you wanted to give your users the option of logging into a different library you’d have to reproduce the full <select> tag from your staff client’s login page.  View the source to find it.

Interface Test: Editing from the additem table

One of the custom reports I’ve been using recently is one that shows me the most expensive items in the catalog. I’m not trying to figure out which book to sneak out under my coat, I’m trying to find data-entry errors which might cause problems for the patrons.

You lost that paperback? That’ll be $4399.00.

The trouble is, once I’m cruising through this report making corrections I’m quickly frustrated by the interface for adding items.additem-interface

The list of items is in its own container with the css property “overflow:auto” so that if it exceeds the constraints of the container it’s in it will display scrollbars. It always displays scrollbars. You have to scroll to the right to see the item’s replacement price, then back to the left to find the Edit link. And it’s hard to be sure you clicked the Edit link in the correct row, because once you’re at the Edit link you can’t see the price anymore!

What if we could access the Edit and Delete functions from anywhere in the row? Inspired by WordPress’s inline edit menu I worked up this example:

additem-inline-edit

Try navigating anywhere in the table of item details and clicking a table cell. You’ll see Edit/Delete links appear for that row. Implementing this change would allow the user to jump to the Edit or Delete functionality from anywhere in the table eliminating the need to scroll back and forth for the static links.

The advantage to the method used in this example is that it’s simple: no generating tooltips or modal dialogs, just a simple append of the Edit|Delete links to the table cell which gets clicked.


$("td").click(function(event){
var $tgt = $(event.target);
if($tgt.is("a")||$tgt.is(":first-child")||$tgt.is(":nth-child(2)")){ return true; } else {
var rowid = $(this).parent().attr("id");
num_rowid = rowid.replace("row","");
$(".linktools").remove();
$(this).append("<span class="linktools"><a>Edit</a> | <a>Delete</a></span>");
}
});

The disadvantage to the resulting UI is that it could suggest to the user that clicking Edit or Delete will edit or delete just the contents of that cell, which is of course incorrect. It wouldn’t be good for a librarian to expect a click on “Delete” to delete, for instance, only the value contained in the replacementprice field and find that the entire item had been deleted.

I’m not sure how to mitigate that confusion while retaining the script’s simplicity.

Update: Here’s an alternate, slightly more verbose version.