Category Archives: Koha UI

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.

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:

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.

[sourcecode language=”javascript”]

$(“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(“Edit | Delete“);
}
});

[/sourcecode]

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.

Interface test: Collection code groups

Does your library have too many choices on the OPAC’s advanced search page? From the point of view of our librarians we don’t, but I think from the point of view of the patrons we do. 43 choices? And many of those categories encompass the same materials or genres. You could easily group our categories using format, audience, or other criteria:

DVDs: DVD, DVDJ, DVJN, DVDN
Videos: AV, AVJ, AVJN, AVNF
Movies: DVD, DVDJ, DVJN, DVDN, AV, AVJ, AVJN, AVNF
Books for adults: AF, MYS, SCI, WES, LP, LPNF, PB, BIO, NF
Large Print: LP, LPNF

It’d be great if you could define “category groups” in Koha to allow patrons to easily search multiple categories at once. Until that comes about, how can we approach the problem from the front end?

Selecting Multiple Categories with JavaScript

Here’s a little experiment I worked up. This is just a static example page to demonstrate the selections. Some parts of the OPAC omitted for simplicity.

Try clicking the links at the top of the category table. Clicking “Books” will select all collection codes which I’ve defined as a book for adults. Clicking “Audio Books” will select any category which could be defined as an audio book, whether it be on CD, cassette, or Playaway.

All the functionality of this example could be layered on top of the OPAC using existing avenues for customization like the opacuserjs system preference. It’s not very efficient to set up, however, because you have to hard-code all your collection codes within the JavaScript. That means that you have to update your script any time you add a category.

[sourcecode language=”javascript”] var books = “#ccode-1,#ccode-5,#ccode-12,#ccode-13,#ccode-14,#ccode-15,#ccode-16,#ccode-17,#ccode-18,#ccode-19,#ccode-27”;
var movies = “#ccode-2,#ccode-3,#ccode-4,#ccode-6,#ccode-23,#ccode-39,#ccode-40,#ccode-41”;
var lp = “#ccode-13,#ccode-14”;
[/sourcecode]

Defining your “supercategories” could be as difficult as defining your original categories in Koha. What criteria do you use? Audience? Format? Content? In my example I mix all three. Would that be confusing to patrons? I may yet add this to our OPAC, but I’ll have to ponder these issues a little more.

Colorizing the Cart and Lists buttons

The OPAC’s Cart and Lists buttons are an unusual construction. Their appearance is the result of a rather convoluted combination of CSS and HTML designed to give nice anti-aliased, rounded corners and flexibility when the text is resized. Try increasing the font size in your browser (Ctrl +).

The technique to create these buttons was adapted from Scalable CSS Buttons Using PNG and Background Colors. If you’re interested in understanding the real nuts and bolts of the technique I suggest you read through that article. I’m going to cover just the details we need to look at for customizing the default appearance in Koha. [Edit: The link no longer works, sorry.]

There are several options we need to cover when changing the buttons’ appearance:

The link and link hover color
The button background-color (default and hover)
The button border

The Cart and Lists buttons each have their own ID in the HTML for reference in the CSS: #cartmenulink and #listsmenulink. Let’s look at the Lists button for simplicity’s sake.

1. The link color

The link color is the most straightforward one: Target the A element with the #listsmenulink ID:

[sourcecode language=”CSS”] a#listsmenulink { color: #E5CCE6; }
a#listsmenulink:hover { color: #FF99FF; }
[/sourcecode]

2. The button background-color (default and hover)

The buttons have both a default background color and a hover background color. Set them by targeting the #listsmenulink ID:

[sourcecode language=”CSS”]

#listsmenulink { background-color : #6600CC; }
#listsmenulink:hover { background-color : #9900CC; }

[/sourcecode]

If we’re just changing background colors, and not images, on the button, how is it possible that we get a nice gradient? The answer is in this part of the default CSS:

[sourcecode language=”CSS”]

#listsmenulink[class] {
background-image : url(../../images/button-background-gradient.png);
background-position : left top;
}

[/sourcecode]

That’s a PNG file with alpha transparency. It overlays the solid background color and softens it with a gradient. If you like the gradient you can leave this part of the CSS without overriding it in your custom stylesheet. It will work with whatever background color you specify. If you want to turn it off to have a solid-color button, use this:

[sourcecode language=”CSS”]

#listsmenulink[class] {
background-image: none;
}

[/sourcecode]

3. The button border

Changing the button border is the trickiest step because it requires an image editor. The button border consists of a single background-image:

How the button would appear if the border image had transparent corners

The image gives the button its border color. The center of the image is transparent. The corners are opaque, colored to match the blue of the default background of the search bar. The corners have to be opaque because they have to mask the square corners of the HTML element behind them.

Changing the background color means the corners no longer match what is behind them

The fact that the corners are colored to match the default background means that if you try to change that background color your buttons will no longer match.

At the moment the only solution for those wishing to make changes to the button background is to recreate it from scratch. I’d like to share the source files I’m using so that in the future it’s easier for Koha users to make this change themselves. I use Photoshop 7 much of the time (yes I know it’s old), so I’m offering that version. I also recreated the graphic in Fireworks MX (again, old) and Inkscape .046 (yay, up to date!).

Photoshop 7	koha3-opac-button-background.psd	29.4K
Fireworks MX	koha3-opac-button-background.png	39.5K
Inkscape 0.46	koha3-opac-button-background.svg	5.2K

Whatever program you use to edit these files, there are two basic steps to achieve the right look:

Edit the stroke of the button shape (the border color).
Change the color of the opaque corners.

Our edited button background image gives us corners that blend perfectly with our custom background color.

After your file is edited to your satisfaction the next step is to export it in a web-friendly format:

If you’re using Photoshop use File > Save for Web and choose PNG-24 with the Transparency option checked.
In Fireworks, your Optimize setting should be PNG32 with the transparent matte option chosen.
In Inkscape, use the Export Bitmap option to export the Drawing only. In my tests Inkscape exported the 32-bit version (the version with alpha transparency) by default.

What About Internet Explorer 6?

Users of Internet Explorer 6 will see a solid-color button with square corners.

One major downside of this method of styling the buttons is that it doesn’t work properly in Internet Explorer 6. IE6 doesn’t support PNG files with alpha transparency. The good news is that users of IE6 will still get a usable button. The bad news is that it won’t be very pretty.

Options Going Forward

If we’re already excluding users of Internet Explorer from the rounded button experience, why not use pure-CSS rounded corners? We could eliminate all the time and effort demonstrated in this article with some simple [if proprietary] CSS. Something like this:

[sourcecode language=”CSS”] #cartmenulink,#listsmenulink {
color: #336600;
padding: .7em .9em .7em .8em;
margin: .5em .5em .5em 1.5em;
text-decoration:none;
-moz-border-radius: 7px;
-webkit-border-radius: 7px;

}
#cartmenulink {
border:1px solid #336699;
background: #93d869 url(“../../images/cart-button-background.png”) top left repeat-x;
}
#listsmenulink {
border:1px solid #006699;
background: #9FBFFF url(“../../images/lists-button-background.png”) top left repeat-x;
}
[/sourcecode]

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.

Using *-border-radius to style rounded corners. Click to view full-size.

Grabbing eyes with styled messages boxes

I got a question yesterday on the Koha IRC channel about changing the background of message which appear onscreen during check-in operations. Aparently librarians were not noticing the messages, and the questioner wondered if those messages could be styled in a different way.

Koha prompts the user to return an item to its home library with a message box

It’s possible to customize Koha’s staff client just like it’s possible to customize the OPAC. At the moment, though, the staff client lacks one useful option: a means of injecting custom inline CSS as we can with OpacUserCSS. The staff client does have intranetuserjs, and that gives us an opportunity to get around the shortcoming.

PLEASE NOTE: As the manual says, “IMPORTANT: This system preference is an advanced option. If you enter a value with incorrect syntax you can make it very difficult to access the staff interface.”

Here’s how intranetuserjs gets added to the markup. From the template:

[sourcecode language=”html”]

//<![CDATA[

//]]>

[/sourcecode]

IF the intranetuserjs system preference has anything in it, the template will include it, wrapped in the appropriate <script> tags. Here’s how we’ll bend the rules to get our custom CSS in: Add this to the intranetuserjs pref:

[sourcecode language=”html”] //]]>

/* Insert custom styles here */

//<![CDATA[
//]]>
</script>
[/sourcecode]

The first thing we do is close the <script> tag which was automatically opened by the template, which expected us to add JavaScript content. We add our custom <style> tag, then re-open the <script> tag. The template is going automatically add a closing <script> tag, so we've got to add an opening one or risk breaking things.

With that in place we can add our custom CSS. The message box gets its background from an image. The simplest way to customize its appearance is to remove the image and add a custom color:

[sourcecode language="css"] div.message { background: #CCFF00 none; }
[/sourcecode] Remove the background image and add a custom color

Or use your own background image:

[sourcecode language=”css”] div.message { background:white url(//static.myacpl.org/public/img/koha_blog/sites/2/squidfingers-pattern_141.gif) scroll left 0;
}
[/sourcecode]

Eye-catching but not very readable!

If you’re going for really eye-catching, you’ll have to go for an animated background image!

Please return Understanding interpersonal communication / to RPL

If you find a background image you like, remember: copy the image to your own server. Don’t hot-link it from someone else’s. Nefarious webmasters are likely to swap out the image for something you don’t want to see!

Of course I don’t really recommend that you use an animated background. As you’re approaching this kind of change, please remember: changing the style of Koha’s default message box will change all instances of that style box. Koha re-uses that style for displaying informational messages throughout the interface. The staff at the circulation desk may like it, but the cataloger doing MARC imports may not!

Moving around your book covers

I often hear people ask if they can have their book covers on the left-hand side of the search results list. This is one of the aspects of Koha 2.x that some people miss. Because the search results are in a table, you can’t simply change something in the CSS to move the images to the other side of the screen. Without changing the template itself, what can we do?

Usually my response is live with it, but it occurred to me yesterday that jQuery could handle this:

[sourcecode language=’javascript’] $(document).ready(function(){
$(“.searchresults tr td:last-child”).each(function () {
$(this).prependTo($(this).parent());
});
});
[/sourcecode]

After the standard leading “(document).ready” stuff, the script starts by looking for elements inside anything with a class “searchresults.” That’s a <div> that surrounds the search results table. We’re looking for any <td> which is the “last child” of a <tr>. That is, the last table cell in each table row. jQuery’s each() function lets us loop over each instance of those last-child <td>’s that we find and perform some action on it.

[sourcecode language=’javascript’]

$(this).prependTo($(this).parent());

[/sourcecode]

This is the action we’re performing for each <td> our script matches. “$(this)” is how we identify the matched <td>. Then we use the prependTo() function to “cut” that <td> and “paste” it at the beginning of the row. Notice the element we’re prepending to is “$(this).parent().” parent() selects the element which “contains” $(this): <tr> contains <td>, so we’re moving our <td> to the beginning of the row.

Paste the script into your opacuserjs system preference and try a search. It works in my test, but don’t take my word for it. Test carefully and let me know if you see any problems with it.